關於淘點點面試中碰到的架構問題

       從事開發工做兩年來，從未寫過隻言片語，俗話說的好」好記性不如爛筆頭「，最近心血來潮開始想慢慢寫點博文，不只是知識的積累仍是爲了若干年後回頭看看當年努力的過程，但願把這個養成習慣並堅持下去，囉嗦了這麼久 來點乾貨把。

      以前面試淘點點的時候被問倒得一個問題至今牽掛，因爲工做環境的限制，我沒能接觸到一些大數據量的併發工做，也沒能有機遇參與複雜系統的設計，而我學習複雜或高併發系統的惟一途徑就是閱讀源碼，慚愧的是，至今也只閱讀了Tomcat的部分源碼，因而我在oschina上貼出問題與互聯網猿一同分析（你們能夠先看看問題：關於淘點點面試中碰到的架構問題），很是感謝你們的意見，尤爲是@林中漫步 @JerryLin 兩位先生 最終肯定兩鍾實現思路：

一、具備排序功能的隊列

二、Redis+定時器

思路 1

原理：第一種思路也就是你們推薦的延遲隊列實現的原理，其就是一個按時間排好序的隊列，每次put的時候排序，而後take的時候就計算時間是否過時，若是過時則返回隊列第一個元素，不然當前線程阻塞X秒，這個也是JDK 自帶 DelayQueue 的思路。詳細可看源碼

代碼實現：待實現後補充

思路 2

原理：第二種思路須要利用Redis的有序集合，說到使用 Redis 就不得不考慮Score的設計，由於它直接決定你代碼的複雜度，你思路的清晰性，在這我並無採用 林中漫步 先生的設計，而是經過精確到秒的時間作Score（去掉毫秒），而後使用線程每一秒掃一次，使用當前時間做爲zrangeBysocre命令的Score去查詢。詳細請看代碼。

業務場景：按京東一天500萬的成交量，一天主要成交時間爲8小時，計算得出每秒173個訂單，固然實際上訂單不能均勻分佈在每秒，但咱們主要爲了論證思想的可行性。

代碼實現：這裏首先我簡單的利用Spring Scheduled做爲訂單的生產者，每一秒製造170個訂單，放入Redis，注意Score的生成，爲當前時間的後60秒，removeMillis()生成去掉毫秒的時間戳做爲Rredis的Zadd方法的 Score（不瞭解的能夠百度下）。

第二步：一樣利用Spring Scheduled 一秒鐘心跳一次，每次利用當前時間做爲Key 從Redis 取數據。

通過測試，沒有出現漏單的狀況，這只是簡單的實現，不少地方能夠優化，在實際中用也可能會出現不少問題，須要不斷完善，此案例只是提供思路，另外我以爲JDK的 DelayQueue 相對於Redis來講沒有那麼好，由於Queue畢竟每次取一個，若是同一時間的比較多可能不能符合當前這種時間嚴謹的需求，另外他是單機的，有時間我去研究下kafka、Rabbit的延遲隊列再來補充。

終於寫完了，由於公司的代碼是加密的，因此不能上傳源碼了（其實也沒得什麼上的，哈哈），另外本人技術有限不免會有紕漏或者錯誤，歡迎拍磚，另外但願本身之後可以堅持寫技術日誌。

版權全部，轉載請註明出處 http://my.oschina.net/u/926166/blog/522227