也談淘點點60s短信訂單的架構設計

1. 前言##

看到了這個 http://www.oschina.net/question/926166_2137672
而後有人寫了博客還分析設計了一下 http://my.oschina.net/u/926166/blog/522227

本人最近對架構設計較感興趣，下面是個人設計，能夠作到極大化性能和水平擴展，全部的性能issue都在網絡IO。redis存儲方面輕鬆支持同時上億個訂單。

2. 基於redis的詳細設計##

1. 使用一個高可用的時間序列發生器服務器。timeserver。
2. 訂單server產生了訂單以後當即往redis的訂單號服務器寫一條記錄，key爲timeserver的nanosecond，存儲類型爲sorted set。把訂單的詳細信息寫入另外一個redis的詳單服務器集羣(用訂單號hash寫入)。
3. 訂單服務器有一個定時器線程，60s運行一次，時間到了發送一條消息（包含time server的當前nanosecond）給短信發送server。
4. 短信發送server收到nanosecond的消息後，去redis訂單號服務器取出全部小於該nanosecond的訂單號，開啓多個協程用訂單號去redis詳單服務器集羣拿到詳單數據，發送短信。
5. redis配置成高可用。訂單業務server和短信server都是無狀態的，能夠橫向水平擴展。

3. 性能估計數據量估計##

nanosecond爲19個字符，而且nanosecond做爲訂單號，假設爲20字符，那麼20byte*100,000,000，一億個訂單的話，redis的訂單號服務器須要大約 1.8GB 的內存。而redis的詳單服務器能夠水平擴展，存儲不是問題。

4. 架構點評

1. 訂單server和短信server都是無狀態，可水平擴展。
2. redis存儲節點高可用，redis詳單服務器集羣可水平擴展。
3. 協程處理拿訂單數據和發送短信，簡單高效。
4. 儘可能避免了各類可預見的性能問題，例如：什麼定時器，每隔1s輪詢一次等等，另外也有對redis進行屢次請求訂單號的，都對性能有一些影響。
5. 有的人的設計甚至把隊列設計到了訂單server內，這嚴重影響了訂單server的擴展性，若是一旦訂單server掛了呢？呵呵。
6. 有人想要採用MQ的方式來作，可是如何搞定延時就是個大問題，由於MQ的方式是，Producer發送了以後，Consumer會當即接收到，若是你在Producer這邊緩存60s以後在發送，那萬一在這段時間該Producer掛了呢？呵呵。這裏補充下，有人提到RabbitMQ的延遲隊列，的確也是一中更加簡單的方案。先發送到隊列1，隊列1不處理，超過60s隊列系統自動發送到隊列2，隊列2的消費者進行處理。也是簡單。呵呵。

##5. 總結##

1. 這是一個很是實用的需求。
2. redis是一個好東西，由於redis的設計和接口足夠簡單，因此咱們沒有太多想象，因此咱們的設計也足夠簡單。簡單纔可能健壯。