哎。。。。
企业级高并发,切记减少内存式锁生产。这样的设计一看就知道是象牙塔出来的,没真的经历过。
一般来说这种流水号,在需要的时候再惰性生成,就已经晚了,要考虑负载前置。
你的业务场景不充分,补充更多业务场景可能会导致solution变化,但是就目前这样的做思考题来说已经足够。首先你的业务场景有一个前提,订单号并不需要严格按照进入系统的时间来区分流水先后,因为你已经是高并发了,快1,2个毫秒,订单号一定要按顺序,这除非找茬,不会真实存在于系统之中。所以,你可以采取高性能Q,预先生成流水号(关键点1),按照业务量分片(关键点2),进行分级缓存(关键点3)。
一级缓存肯定在内存里,你可以准备大约10秒的流水号在内存里。由十个分片控制,在业务逻辑取流水的时候,由算法控制去不同片取。(轮询也好,计数也好,这都随便,看你业务场景)这样的话,好处是你加锁等待时间,平均来说,除以10了。
切记架构设计是软硬件一体设计,二级缓存放在高性能SSD里面,每5秒查询下一级缓存是否接近临界值(比如流水还剩15%),则尾端补充。
当然,时间间隔什么的,都是示意,要按照实际场景测试优化。和上面所有的内存同步式取法不同,我这个还支持scale out。