秒殺系統的設計猜測

首先聲明，本人沒有設計過秒殺系統。

僅僅是今天在面試時被問到了這個問題。感受回答的不是很是好。回來後細細想了想再加上請教同事，並查詢了一些資料。

整理出了一個思路。

一、首先秒殺系統要考慮到多併發的排序問題，同一時候來了上千個請求，那麼首先要負載均衡這些請求。

將這些請求分散到不一樣的server上，那麼作負載均衡的有Nginx等。


二、請求有先來後到問題。則需要排序，那麼排序就要用到隊列。
     隊列的實現方式：
     a、 java concurrent 包中有幾個Queue。如 LinkedBlockingQueue （線程安全的堵塞隊列）。
      ConcurrentLinkedQueue（採用CAS操做，來保證元素的一致性），ArrayBlockingQueue。

     b、MQ Server的消息隊列（如ActiveMQ）。固然用MQ有個問題，假設你從隊列中取出來的消息，可是寫
        失敗的怎麼辦？ 因爲MQ是異步的。它當時並不返回成功或失敗的結果，假設過了一下子
       返回的結果是失敗，該怎麼辦？

       這時就要用NoSQL 來作一個保證機制了，如NoSQL中也要有個字段來標識
       消息是否寫成功，假設沒有寫成功。則再將失敗的消息寫回MQ。

三、用戶搶到商品後，怎樣保證該商品再也不被其餘用戶搶到，這裏面就涉及到一個對數據的原子
      操做問題。或加鎖問題。

      a、假設要用數據庫實現（因爲假設定比較嚴格的鎖，則對數據表的操做是原子性的，比方：對行加排它鎖）。

      b、但數據庫的性能是比較低的因爲它歸根結底要對IO進行操做，
          假設對性能要求很是高，則可以用NOSQL來實現。因爲NOSQL是常駐內存的，
         比方Redis。因爲Redis的操做也是原子性的，這是就可以用Redis來保存商品的信息。

        
         假設Redis的性能也不夠用的狀況下怎麼辦？ 我想是否是還有性能更高的NoSQL: 比方 MongDB，memcached？ 

以上僅僅是設想，沒有實際用過。歡迎拍磚。