订单号

最近做的项目的性能调优中关于幂等设计的一些总结 场景：假设有这样一个方法，包含了一些DB操作，check if existing then update else save. 如果两个线程同时去执行这个方法，并且他们处理的是同一条数据，期望应该是其中一个线程是save，另外一个是update。但是有可能线程的处理时间相当重合，线程A在check的时候，线程B也在check，这时A和B都认为数据不存在，都去save，在 数据库 有unique 约束的情况下其中一个操作会失败，而我们期望的可能是后面一个操作应该update（取决于具体业务）。 这是很典型的多线程问题，check － then do something，在单系统环境中这很容易用线程同步来处理(syncronised). 但是如果是分布式系统，这两个线程在不同的server上面，syncronised 是不会起效的，而且同步往往降低效率，并不是我们想要的。 拥有相同参数的多次请求对系统造成的副作用应该是相同的，这就是幂等性。在这个例子里面就是说保证相同的ID组合只会插入一条数据到DB里面，如果一个请求是save，后续的都应该update这条。在单系统中也可以用幂等的设计来规避使用syncronized，因为那会降低效率。一般情况下数据库就能保证这种幂等性－－用unique关键字，以上面的场景为例

解决方案：指定 GROUP BY 时，选择列表中任何非聚合表达式内的每个属性名都应包含在GROUP BY列表中，或者GROUP BY表达式必须与选择列表表达式完全匹配。 错误用法： select top 1000 订单ID,客户ID,订单号,实付金额,主订单ID FROM [TRA].[dbo].[订单] group by 订单ID order by 订单ID 报错： 正确用法1： select top 1000 订单ID,min(客户ID),min(订单号),min(实付金额),min(主订单ID) FROM [TRA].[dbo].[订单] group by 订单ID order by 订单ID 正确用法2： select top 1000 订单ID,客户ID,订单号,实付金额,主订单ID FROM [TRA].[dbo].[订单] group by 订单ID,客户ID,订单号,实付金额,主订单ID order by 订单ID min最小值： 在没用group分组时，此刻整张表为一个组 ，min返回的是这一列中数据最小的数据， 使用group分组时，min返回的是所在组的最小数据. 使用Group By子句的时候，一定要记住下面的一些规则： （1）不能Group By非标量基元类型的列，如不能Group By text，image或bit类型的列 （2

Small ERP:需求 摘要：打算写一个小型的ERP，目标：20操作人员以下，需求先写简单点，以后扩充。 ------------------------------------------------------------------------------- 总帐：凭证 应收：销售发票 其他应收单 收款单 应付：采购发票 其他应付单 付款单 采购：采购订单 到货单 到货退回单 销售：销售订单 发货单 退货单 库存：销售出库单 采购入库单 材料出库单 成品入库单 调拨出库单 调拨入库单 盘点单 生产：生产订单 领料单 BOM : ATO PTO Optional MRP : 预测订单 MRP计算 ROP : Re-Order Point (定量订货模型fixed-order quantity model)(定期订货模型fixed-time period model) (专有模型：批量折扣模型 单周期存储模型) (经常使用：任意补充系统 单箱系统 双箱系统)(ABC分析法)(周期盘点) WorkFolow设计:状态工作流,序列工作流。 DataModel设计:可添加字段,二次开发。 ------------------------------------------------------------------------------- 凭证： 凭证类别 转 字 001

3 月，跳不动了？>>> 在电商业务中，商品的交付都是围绕订单号来进行的。一般的基础流程都是创建订单、支付订单、交付订单、签收订单。 基于订单，我们可以做很多工作。比如，建立一条交易的数据总线，定期核对商品的交付情况，以此来保证数据的最终一致性。再比如，通过订单号，将各个系统中的数据串起来，扮演请求 traceId 的作用，等等。 客户端要购买商品，有两种程序上的交互方式： 第一种、 第一步、客户端提交待购买的商品信息，之后，服务端创建订单，并将订单号返回给客户端； 第二步、客户端提交订单号给服务端，进行支付。 第二种、 客户端提交待购买的商品信息，服务端创建订单，并进行支付。 两种方式的本质区别在于： 交易的过程，客户端是否需要知道订单号的存在 拿苹果手机的 IAP 支付举例，通俗的讲，就是在 APP 内支付。简单介绍一下苹果支付的基础流程： 在苹果服务后台创建商品，创建的商品需要和我们实际的商品做对应。 客户端和苹果服务交互，完成用户扣款 客户端获取苹果服务返回的扣费凭据，提交给服务端 服务端请求苹果服务，验证凭据的有效性，决定是否给用户交付商品 在这个流程中，订单号应该在步骤1创建，还是在步骤4创建呢？如果在步骤4创建，在用户行为上，就缺失了用户尝试支付的订单数据，数据表中也只存在用户成功发起支付的订单。 来源： oschina 链接： https://my.oschina

#高并发下单主要包括以下几个方面： 分库分表 多应用实例全局唯一订单号 数据库连接 买家查询订单 卖家查询订单 扩容问题 业务拆分 一、分库分表 随着订单量的增长，数据库的发展主要经历以下几个步骤： 1主-1从架构 双主-多从架构，读写分离 表分区，提高并发 分表，提高并发 Master更换SSD 分库，分表，提高并发 ###分库分表实现过程 订单分成16个库，每个库64个表进行存储，总共1024个表，mysql单表性能超过千万级别会导致性能严重下降，假设按千万计算，最高可以存储百亿级订单。随着存储问题的解决，但复杂度会随着增加： 首先是多库怎么保证生成的订单号全局唯一； 其次查询复杂度的增加； 买家查询订单时，应该去哪个库哪个表里查找，卖家应该去哪查； 再大的存储量，随着数据量的增长，终究是会遇到瓶颈，该怎么扩容。 ##二、全局唯一订单号 这里采用Twitter snowflake方案，全剧唯一ID生成由：时间戳+机器ID+自增序列（+userid后两位）； 订单的生成过程直接在应用实例中生成，直接在内存中计算，且计算过程分散到每台应用实例中，解决性能问题，userid后两位在后面解释。 ##三、数据库连接问题 分库分表后，要连接数据库变的复杂起来，分为两种方案： ####一、jdbc直连 此种方式需要在应用代码中，自己计算订单应该进入哪个库，可取订单的后两位，先对库16进行取模

微信支付宝支付常见问题记录 文章目录 微信支付宝支付常见问题记录 微信 不得不吐槽 界面设计规范 支付/退款结果通知 沙箱功能 APP支付 支付宝 界面设计规范 微信 官方文档： https://pay.weixin.qq.com/wiki/doc/api/index.html 官方对参数的规定，建议使用之前先阅读一下，特别注意时间戳单位是秒： https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=4_2 商户订单号只要未支付或者支付失败就可以继续使用该单号直至成功，支付成功后申请退款，退款成功后该商户订单号不可再使用 用订单号a生成订单1时未支付，接着再用原来的订单号a重新生成订单2，接着app支付订单1成功，那么app再发起订单2支付时微信会提示账单已支付 订单号被关闭后不可再重新使用，因此每次交易都需要生成新单号 微信下单时虽然可以设置订单失效时间，但查询订单时却没有订单超时失效此状态，只会显示未支付状态 不得不吐槽 这里不得不吐槽一下微信，开发人员可能想偷懒，竟然还在使用xml,一开始用xml我理解，都过了这么久就不考虑升下级吗； 还有提供的sdk也是一般般，都21世纪了，就不能像支付宝一样提供个依赖吗，还要去手动下载sdk集成（后面发现maven仓库上有一个sdk版本 https:/

前段时间帮一个朋友的基于ecshop开发的商城加入微信扫描支付功能，本以为是很简单的事儿——下载官方sdk或开发帮助文档，按着里面的做就ok了，谁知折腾了两三天的时间才算搞定，中间也带着疑问在网上找了不少技术文章，却发现都只是比较粗略的写他们是怎么开发接入的，并没有解决我遇到的问题...，唉，有时候真心的感觉‘只能靠自己’。本文就是想把自己遇到的问题及解决办法写出来，让做这方面开发的朋友有所帮助！ 　　开发之前，先查看官方 【扫码支付】开发文档 ，扫码支付分为以下两种模式： 　　△ 模式一: 　　 遇到的问题：第一次扫描二维码还能正常扫描，未付款再次扫描会提示：ok 或 请求商户信息超时HttpCode非200 ——此问题尝试通过各种途径寻找解决办法都无果，在这里希望有知道朋友能给与解答，谢谢！ 　　△ 模式二: 　　 注意： 不可以直接用商城的订单号作为交易订单号(out_trade_no)，否则再次生成微信扫码支付二维码时，接口会提示： 商户订单号重复 ，无法重新生成。 　　那么酱紫问题来了，应该怎样设置交易订单号，还能保证后面通过接口查询微信商户平台里的相应订单信息或实现对账？可行的办法是：扫码之前的统一下单接口，out_trade_no不要传入商城订单系统的订单号，而是重新生成一个新的唯一流水；再增加一个订单号和微信支付交易订单号(out_trade_no)对应表，如下：

支付宝配置： package alipay; import java.io.FileWriter; import java.io.IOException; /** * Created by Administrator on 2019/7/6. */ public class AlipayConfig { // ↓↓↓↓↓↓↓↓↓↓请在这里配置您的基本信息↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ // 应用ID,您的APPID，收款账号既是您的APPID对应支付宝账号 public static String app_id = "2016100100636987";//例：2016082600317257 // 商户私钥，您的PKCS8格式RSA2私钥 public static String merchant_private_key ="MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCQ4JdtPp86OXH26BFAlfoQF/zk66lsTzUrRBOm7HqCwfxLTFvRffhS/UHBwpETySYbpiuAxfnKgsnP+AdrfPetpsAPhQf7IYfQTcdAoWJLP3j3+2emAYGRmUCcyehR3oCmQNeXg8el6kD8bMiG+sgVYCMsUcd0T49kfd85NBaMV1rtW

　　在我们支付系统设计中，经常会遇到这样一个问题，防止用户重复支付。用户明明只想购买一次，却因为系统问题，导致重复支付，带来额外的物流成本和扯皮退货的运营成本，对商家的信誉和系统的体验很不好。 　　那么实际我们在设计支付系统时，如何来避免这一问题呢。 为什么会出现重复支付 　 1.客户误操作点了两次 　　比如下单的按键在点按之后，在没有收到后端返回之前，按键的状态没有设为已禁用状态，还可以被按。 　 2.支付渠道端返回超时 　　用户在收银台页面点击某个支付方式后，在支付渠道（比如网银或者微信支付宝）上完成付款，但是渠道端返回的异步通知超时，导致系统付款状态尚未更新，用户并不清楚到底订单是否支付成功，而导致再次支付。 如何防止重复支付提交 　　在我们实际支付系统设计中，我们系统设计人员经常无法区分商品订单和支付订单之间的关系，经常混为一谈。所以本文谈论的是支付订单的防重复，商品订单的防重复需要另外讨论（包括用户误操作、客户端和后台时延、以及支付和商品订单状态更新不同步等问题）。 　　对于支付重复提交的处理，一般有两种主流的办法：一种是京东收银台的，京东允许客户对一笔商品订单做多次支付，而对于第二笔以上的支付，走退款流程；另外一种是对订单幂等要求比较高的银行收银台，往往是要求商品订单状态和支付订单状态强一致性。 　　这里，我们重点讨论第二种方式，保持支付订单的幂等性来防止重复支付。 　

function order_no() { return substr(date('Ymd') . substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8), 4, 16); } 用uniqid获取一个基于当前的微秒数生成的唯一不重复的字符串（但是他的前7位貌似很久才会发生变动，所以不用考虑可删除），取其第8到13位。但是这个字符串里面有英文字母，咋办？ 用ord获取他的ASCII码，所以就有了下一步：用str_split把这个字符串分割为数组，用array_map去操作（速度快点）。 然后返回的还是一个数组，KO，在用implode弄成字符串，但是字符长度不定，取前固定的几位，然后前面加上当前的年份和日期，这个方法生成的订单号，全世界不会有多少重复的。 当然，除非你把服务器时间往前调，但是调也不用怕，哥不相信他会在同一微秒内下两次订单，网络数据传输也要点时间的，即便你是在本地。 来源： CSDN 作者： qq_40434718 链接： https://blog.csdn.net/qq_40434718/article/details/103933256