也谈淘点点60s短信订单的架构设计

本人最近对架构设计较感兴趣，下面是我的设计，可以做到极大化性能和水平扩展，所有的性能issue都在网络io。redis存储方面轻松支持同时上亿个订单。

使用一个高可用的时间序列发生器服务器。timeserver。

订单server产生了订单之后立即往redis的订单号服务器写一条记录，key为timeserver的nanosecond，存储类型为sorted set。把订单的详细信息写入另一个redis的详单服务器集群(用订单号hash写入)。

订单服务器有一个定时器线程，60s运行一次，时间到了发送一条消息（包含time server的当前nanosecond）给短信发送server。

短信发送server收到nanosecond的消息后，去redis订单号服务器取出所有小于该nanosecond的订单号，开启多个协程用订单号去redis详单服务器集群拿到详单数据，发送短信。

redis配置成高可用。订单业务server和短信server都是无状态的，可以横向水平扩展。

nanosecond为19个字符，并且nanosecond作为订单号，假设为20字符，那么20byte*100,000,000，一亿个订单的话，redis的订单号服务器需要大约 1.8gb 的内存。而redis的详单服务器可以水平扩展，存储不是问题。

订单server和短信server都是无状态，可水平扩展。

redis存储节点高可用，redis详单服务器集群可水平扩展。

协程处理拿订单数据和发送短信，简单高效。

尽量避免了各种可预见的性能问题，例如：什么定时器，每隔1s轮询一次等等，另外也有对redis进行多次请求订单号的，都对性能有一些影响。

有的人的设计甚至把队列设计到了订单server内，这严重影响了订单server的扩展性，如果一旦订单server挂了呢？呵呵。

有人想要采用mq的方式来做，但是如何搞定延时就是个大问题，因为mq的方式是，producer发送了之后，consumer会立即接收到，如果你在producer这边缓存60s之后在发送，那万一在这段时间该producer挂了呢？呵呵。这里补充下，有人提到rabbitmq的延迟队列，的确也是一中更加简单的方案。先发送到队列1，队列1不处理，超过60s队列系统自动发送到队列2，队列2的消费者进行处理。也是简单。呵呵。

这是一个非常实用的需求。

redis是一个好东西，因为redis的设计和接口足够简单，所以我们没有太多想象，所以我们的设计也足够简单。简单才可能健壮。