2018-07-18
先占个坑，回头再来完善下这篇文章，有思路想法的欢迎大家留言交流
为什么把这个问题抛出来的，因为了解到有公司的订单号ID本身是随机的，也是杂乱无序的，但是订单号ID的最后1位随机性不强，在一次大促期间引发了严重的事故。
举个例子：
订单号ID的最后1位只会有1，2，3，4这4种可能性，考虑到单位时间内订单量的不确定性，我们通常会写入到一个临时表（订单缓冲表）。
然后会由另外一个程序编写周期性任务处理订单，这个程序通常也是支持分布式的，多机部署的，假若部署了10台，采用tbschedule框架进行订单分片，让每一台机器只处理其中一部分订单，研发小哥们会怎么做呢，由于自己投入了10台机器来干这件事，所以就简单的将订单号按10求余数，根据余数来决定由哪台机器来处理。
问题就来了，按10求余的话，按照上面说的，最后只会有1，2，3，4这4种余数，投入的10台机器最终只会有4机器被分配到订单，另外6台就由于空转，一直闲着。当订单量不高的时，靠4台干活的机器支撑平时系统一直也都还OK的。
大家都知道大促期间系统产生的订单可能是平时的十倍甚至几十倍，就这样在一次大促中，那4台苦命干活的机器终于支撑不住，订单处理的速度远远达不到订单生产的速度，严重的影响了订单履约的时效，一时间用户、商家/司机、客服、运营的压力，最关键的是影响到大家对公司品牌的认可。
暴露出来的问题：
6台机器虽然部署了程序，但是本身处于空转不干活，硬件成本造成了一定程序的浪费。
4台机器在大促期间之所以抗不住，是因为我们对系统处理能力的预估不足，压力测试的模型不够合理
历史上常见的分布式ID方案：
大家可以参见我之前转发的一篇文章，我们依次来寻找解决方案
https://blog.csdn.net/hl_java/article/details/78462283
如何解决：
- ID最后一位采用随机数
- ID最后一位采用机器ID号（机器ID号命名要保证后期取余均匀性）
- ID生成规则不变，在进行任务分片时作为字符串对待先计算出hashcode，再利用hashcode进行求余也是可以的