请问这种业务场景，什么数据库比较合适，或者如何优化此类业务？

试试雪花算法，跟机器和机器时间有关，只要时间不坏就没问题

我的理解是，每插入一条订单，去 redis 拿一个号，然后更新相关的几百条数据

两个方案：

1、从 redis 取到号之后，扔到队列去更新，这样不会阻塞后面的请求，反正此时订单号已经确定，不会重复
2、把取到号的订单写进另一个 redis set，部署一个定时任务，具体执行周期看业务情况，定时取出 set 的订单号，然后进行批量更新相关的几百条数据。

不太清楚为何要单进程？关联100条数据做单纯的累加的话，一个 update 就可以搞定，若是怕中间出错导致数据不一致性，可以使用事务。1000 个订单这种量级的写入并发我确实没有碰到过，但我理解使用集群配合队列削峰填谷，应该是可以消化的。

为解决数据同步问题，只能使用单进程

一个分布式锁就能解决的问题，什么单线程多线程的问题，又不是需要状态的请求接口数据。 就这点数据流 mysql 扛起来都没问题，加个 redis 上把锁，安心睡觉就行了。 其次更新数据库怎么就不能放进队列了？队列本来就是一个正序的 list 结构，队列开个 32 线程跑，跑不过么？

本来很简单的诉求，就是保证数据能顺序的更新，唯一加的要求就是保证是顺序递增的，怎么就被整的这么麻烦呢？