『目的』滿足貫穿從商品展示、搜索、購買、支付等整個流程，電商對於精細化、精準化促銷運營的需求，使多渠道（終端）、多區域化營銷成爲簡單易行的配置操作，提升運營能力。
『目標』保證促銷規則支持分時段設置，多活動可疊加，促銷系統中數據量超過商品信息系統的前提下，促銷內容會根據執行效果快速調整，以強大的促銷系統，保證有序的促銷活動，使促銷系統承擔營銷功能。
『核心改進點』數據模型與運營的貼合度決定的擴展性、靈活性，系統解耦和更強大的數據處理能力
『其他待解決問題』促銷模型較陳舊、擴展性差，促銷系統成熟度低、與其他系統耦合嚴重。
『解決方案』
step 1 ：確定最基本的促銷模型；
step 2 ：在促銷模型基礎上抽象出活動模型；
step 3 ：基礎模型定型，實施解耦相關設計——
系統交互解耦：將直讀DB和存儲冗餘促銷數據的系統修改爲調用服務及監聽MQ邏輯回收：包括將促銷校驗與促銷計算提取爲交易服務，將原先由購物車、交易系統自行處理的促銷邏輯回收提取促銷工具的屬性：諸如類型枚舉、促銷標籤、限購策略、庫存策略等，以期外圍系統儘量少的關注促銷類型，通過促銷ID拿到所需信息直接使用。［未來關注於業務層面的梳理與整合，逐步回收適用於活動模型的其他“類促銷”業務。］step 4 : 完善促銷系統查詢服務，使其具備更強大的數據處理能力和更好的性能表現。
應用架構實現上，從前端頁面到後端邏輯，儘量避免有邏輯與促銷類型直接綁定，全部以插件化方式與促銷模型對接，完全根據促銷類型的配置進行組裝。針對不同維度、條件、優惠、促銷屬性，定製頁面模板及業務邏輯，使得新增一種促銷類型（在已有維度、條件、優惠下）僅需配置即可完成。促銷系統的查詢服務需要同時爲多個系統提供數據，對TPS要求很高，同時促銷的時效性又要求很高的實時性。我們採用的方式是在數據庫前加Redis緩存，提高響應速度，同時監聽MQ，根據事件清理相應的緩存數據。
『需注意問題』
Redis緩存雖減輕了DB壓力，但對於計算密集型應用並未減輕應用服務器壓力，IO未節省且增加序列化開銷；事件驅動清理緩存在讀寫分離場景下，有可能比主從同步更快，造成緩存數據錯誤。
舉措二——重構交易系統『措施——引入業界成熟技術實現方案』
-
集中化配置：一點配置，所有實例可見，更易於管理，且配置修改後，通過熱加載方式，立刻生效，快速便捷。
-
頁面緩存技術：大流程計算結果進行緩存，在一次頁面請求範圍內，後續調用直接用緩存結果，極大提高頁面刷新速度。
-
小版本合併：由於歷史原因，交易系統存在很多版本的結算邏輯。最常用的是統一結算，還有一些特殊類型的結算，如秒殺、一鍵下單、補發貨等等，邏輯與統一結算稍有不同，統稱爲小版本結算。因小版本結算與統一結算大部分邏輯相同，因此新交易系統將二者合到了一起，共享基礎邏輯，而不同的邏輯則單獨處理，極大提高了可維護性。
-
灰度發佈、無縫切換：藉助了Nginx在運行狀態下可以reload配置，而基本不影響對外提供服務的能力。每個Nginx負載兩臺應用服務器，灰度發佈時，將Nginx配置更改爲只負載一臺應用服務器，即可對另一臺進行部署。用戶請求不會導向正在部署中的服務器，從而不影響用戶下單。
-
並行比對：交易系統的計算都和金錢有關，必須慎之又慎，因而提出線上並行比對方案，根據老交易系統比對新交易，保證其邏輯正確。
-
分流：開發分流功能，按照用戶id來分流，正式分流前，先使用測試白名單中的用戶進行預驗證。預驗證通過後，再按比例由低至高逐步切換。
-
Web服務器按需伸縮：基於前面所講的灰度發佈技術，新交易系統很容易做到按需伸縮。正常情況下，每個Nginx負載兩臺應用服務器。雙十一需要擴容時，將待擴服務器ip地址加入Nginx配置，重新reload，該Nginx就可負載更多臺應用服務器了。
交易系統上線後爲備戰雙十一，確保萬無一失，利用老交易系統還未下線的條件進行了線上壓測。爲達到最準確的測試效果，且不影響正常系統運行，噹噹的技術團隊進行如何準備，以及上文重構促銷系統中提到的促銷模型具體設計。
蘇寧
迎戰11.11——四大方向
方向一——關於系統拆分
『前提』技術上分析主流程、分離主幹系統和枝葉系統、根據業務內聚性獨立出主幹系統，做到分別部署。業務上分析電商主要功能與重運營特點。
『執行』根據業務功能拆分出幾大核心系統，包括：會員、商品、庫存、價格、購物車、交易、訂單和內容管理等，並組建對應的研發中心來維護；根據交易環節的系統壓力，獨立出搶購和秒殺系統，拆分出購物券、雲鑽等營銷類的系統，並組建營銷中心。
方向二——關於基礎平臺『主攻解決問題』
-
基礎架構方面包括自建CDN、雲計算和雲存儲；
-
通用系統方面包括短信、郵件、驗證等系統；
-
系統集成包方面括系統之間的通訊、統一驗證和內部管理系統的統一權限；
-
中間件方面包括Session共享、分佈式調用鏈、Redis分片存儲、數據庫的分庫分表中間件、統一配置管理和流控；
-
平臺方面：運維監控平臺，持續集成平臺，大數據分析平臺；以及針對安全的風控系統等。
『Tips』
-
內部通訊方式系統分別選取MYESB和RSF，其中 MYESB是一個安全的集中消息轉發服務系統，提供同步和異步兩種服務接口。RSF類似阿里的Dubbo，提供遠程調用的機制，支持HTTP和TCP通訊服務。
-
持續交付平臺主要包括代碼基礎框架自動生成、代碼質量分析、代碼的自動化部署和代碼權限管理。
-
監控平臺包括對硬件資源、操作系統、中間件以及業務系統的監控。實時日誌系統偏向分析的LogMonitor系統以及針對移動端的監控系統，基於ELK技術, 可以實時監測請求狀態、系統錯誤和進行多維度查詢分析；LogMonitor可以統計分析接口最大、平均處理時間和歷史接口的性能對比。
除通過代碼走查、sonar平臺、各種測試等手段，中心也採用代碼飛檢來確保代碼質量。 代碼飛檢即定期快速評審系統核心代碼。與面向項目組內代碼走查不同的是參加代碼飛檢人員級別相對較高，均爲各個系統負責人、架構師以及總監。當各個系統裸露在大家面前的時候，系統的美與醜很容易被區分出來。通過這種方式，發現優秀代碼以及幕後高手。意想不到的效果是優秀的人才很快浮出水面，而並非靠挖掘。
流程發佈檢查單爲系統的最後一關，需經過產品負責人、開發負責人、QA、測試負責人、DBA、運維人員、以及線上驗證人員對各個環節進行確認，以確保系統上線過程少出問題，即便出現問題也能及時下架。
方向四——關於系統保障『準備一：提高系統負載能力』
step 1 : 根據歷史數據對雙11的流量進行預估，細化到每個系統的PV、UV、峯值TPS，要求每個系統要努力達到這些指標；
step 2 ：對目前系統壓力、容量和相關指標進行統計，按預期流量判斷系統的服務是否滿足要求；
step 3 : 對系統進行自上而下的體檢，針對體檢發現問題制定相關方案。具體體現在對系統架構梳理、關鍵代碼優化以及中間件調優。
『Tips』
架構梳理主要對重點業務的處理流程和處理的鏈路進行審覈。一個系統經常依賴多個系統，一個業務需要多次調用第三方服務，導致流程鏈相當長。在非必要依賴的前提下，可通過依賴調用改成第三方主動推送數據來消除依賴。
『準備二：應急預案』
-
黑名單：主要是拒絕惡意的系統訪問，如：IP黑名單、用戶黑名單。
-
限流：在流量超過系統負載警戒線時，主動丟棄相關的請求，以保全系統，即爲限流。限流可通過防火牆流控功能、中間件的流控功能和流控組件來實現。目前採用的流控組件還支持IP、用戶、URL三個緯度來控制訪問頻度，以防止過度請求。
-
降級：降級可使系統臨時承擔更大的流量壓力，具體策略包括：屏蔽非關鍵業務的入口、關閉影響性能非關鍵業務功能、頁面靜態化、開啓驗證碼策略延緩系統壓力、延長緩存的時間犧牲實時性、放棄後端的補償機制以減少調用鏈時間等。在多大壓力的情況下開啓什麼的降級策略，需要具體問題具體分析。
蘑菇街
迎戰11.11——五個關注焦點
焦點一——穩定性
對已遇到過的問題，及時採用各種方式解決或規避。如：CentOS6.5自帶device mapper存在dm-thin discard導致內核可能隨機crash，解決方式爲關閉discard support，在docker配置中添加“--storage-opt dm.mountopt=nodiscard --storage-opt dm.blkdiscard=false”，且嚴格禁止磁盤超配，磁盤超配可能會導致整個device mapper無法分配磁盤空間，從而使整個文件系統變成只讀，引起嚴重問題。
焦點二——多維度的閾值監控-
實時pid數量監控：由於Linux內核對pid的隔離性支持並不完善，導致需要監控實時pid數量，目前並沒有任何Linux發行版能做到針對pid按照容器粒度進行pid_max限制。
-
內存使用監控：cgroup提供的內存使用值比真實使用的內存值要低。內核memcg無法回收slab cache，也不對dirty cache量進行限制，所以很難估算容器真實的內存使用情況。因此調整容器內存的計算算法，根據經驗值，將cache的40%算做rss，調整後的內存計算比之前想對精確。
-
日誌亂序：跑Docker的宿主機內核日誌中常會產生字符亂序，導致日誌監控無法取到正確的關鍵字進行報警。原因與宿主機和Docker容器中都跑了rsyslogd有關。該問題可通過修改container裏的rsyslog配置，只讓宿主機去讀kernel日誌解決。
-
隔離開關：在壓力大的情況下，爲個別容器進行動態的CPU，內存等擴容或縮容，調整甚至放開磁盤iops限速和網絡的TC限速。健康監測：定期的掃描線上可能存在的潛在風險，以提前發現問題解決問題有備無患。
-
如在不啓動Docker Daemon情況下，離線恢復Docker中數據的方法。方法是：用dmsetup create命令創建一個臨時的dm設備，映射到Docker實例所用的dm設備號，通過mount臨時設備，恢復原有數據。
-
支持Docker容器冷遷移。通過管理平臺界面一鍵實現跨物理機遷移。
Docker集羣須能與現有運維繫統無縫對接，才能快速響應，做到秒級的彈性擴容／縮容。因而以統一的容器管理平臺，實現對多個Docker集羣的管理，從下發指令到完成容器的創建可以在7秒內完成。
焦點五——性能優化-
針對磁盤IO的性能瓶頸，調優像vm.dirty_expire_centisecs,vm.dirty_writeback_centisecs, vm.extra_free_kbytes這樣的內核參數。
-
引入了Facebook的開源軟件flashcache，將SSD作爲cache，提高docker容器的IO性能。
-
通過合併鏡像層次來優化docker pull鏡像的時間。在docker pull時，每一層校驗的耗時很長，通過減小層數，不僅大小變小，docker pull時間也大幅縮短。
唯品會
迎戰11.11——六個設計要點
要點一——系統模塊有效切分
重點解決業務系統在實際運作中業務耦合嚴重，模塊劃分不合理，導致模塊之間邊界不清楚問題。解決方案爲，從整個系統角度出發，梳理整個流程，重新做系統定位，將不同業務子系統做物理分離，減少彼此之間的依賴，使各個子系統獨立部署，出現問題後能快速採取措施，隔離出問題模塊，將故障影響降到最低。
要點二——服務化解耦，集中服務治理基於Spring的Java開發框架獨立自主開發Venus系統, 降低開發複雜度, 提高開發人員開發效率, 提升代碼質量, 規範開發流程。
『Venus框架涵蓋以下內容』
-
數據庫訪問層封裝，支持分庫、分表，連接池優化
-
緩存（Redis/Memcached）接口封裝，連接池優化
-
CRUD服務代碼自動生成（包含數據庫操作）
-
OSP/REST服務調用接口封裝及異步支持
-
ValidateInternals
-
單元／集成測試模版代碼自動生成
-
配置中心
-
中央文檔中心
『Tips』
開放服務平臺（OSP）：其主要目標是提供服務化的核心遠程調用機制，OSP提供了豐富的服務治理能力，如路由、負載均衡、服務保護和優雅降級等，通過OSP，有效的實現了流量控制。服務限流：在系統流量達到極限時的情況，有自動熔斷機制。熔斷器是在服務或者周邊環境（如網絡）出現了異常後主動斷開客戶端後續的使用，從而避免服務崩潰無法恢復。但是在後續時間熔斷將使用小量請求嘗試偵測服務是否已經恢復，如果恢復則將服務再次提供給客戶端調用。
服務降級：通過對不同業務級別定義不同的降級策略，對除核心主流程以外的功能，根據系統壓力情況進行有策略的關閉，從而達到服務降級的目的，例如在線商品信息必須保證優先訪問，對於下線的商品信息，可容許在訪問容量受限情況下，容許關閉下線商品詳情頁面的訪問等。
要點三——增加異步訪問對於系統間實時性要求不高的操作，如執行時比較耗時，可通過異步處理提高調用者性能，提高響應能力，尤其通過異步調用通知非主要流程，加快了系統主要業務流程的反應速度和性能，異步處理機制可起到緩衝的作用，被通知的下游系統可依據自身能力控制處理數據量，避免遭受超負荷的衝擊，保證系統穩定運行，增加了系統可用性。
分佈式異步消息隊列服務器可在宕機後確保消息不丟失，異步系統有重試機制，從而提高系統可用性、健壯性和擴展性。
要點四——多階段緩存，降低後端壓力-
動靜分離，靜態化：靜態化可降低後端壓力，通過用戶瀏覽器緩存靜態資源，失效時間通過cache-control來控制。通過CDN緩存到靠近用戶的節點，提高CDN效率。
-
分佈式緩存：引入分佈式緩存，對緩存數據服務節點做統一集中管理，可支持緩存集羣彈性擴展，通過動態增加或減少節點應對變化的數據訪問負載，通過冗餘機制實現高可用性，無單點失效，不會因服務器故障而導致緩存服務中斷或數據丟失。應用端使用統一的API接口訪問緩存服務器。
-
巧用應用服務器本地緩存：將基本不修改的配置數據、全局數據可以在應用服務器本地緩存，減少對後端緩存服務器實例的峯值衝擊。本地緩存需要謹慎使用，如果大量使用本地緩存，可能會導致相同的數據被不同的節點存儲多份，對內存資源造成較大的浪費。對於頻繁修改的數據、沒有熱點的訪問數據、數據一致性要求非常高的數據，不建議使用緩存。
-
優化複雜查詢，提高數據庫查詢效率，找出關鍵模塊的數據庫慢查詢進行優化。
-
保證在實現功能的基礎上，減少對數據庫的訪問次數；通過查詢參數，減少對錶的訪問行數，最小化結果集，減輕網絡負擔。
-
基於電商系統讀寫比很大的特性，採用讀寫分離技術，通過一主多從，寫操作只發生在主表，多操作發生在從表上，緩解對主數據庫的訪問壓力。
-
藉助於分佈式緩存，緩存提供了遠大於數據庫訪問的性能。當某一應用要讀取數據時，會首先從緩存中查找需要的數據，如果找到了則直接執行，找不到的話則從數據庫中找。在設計時，需要防止緩存失效帶來的緩存穿透壓力。
-
容許一定程度的數據冗餘，對於關鍵模塊，爲了防止對其它模塊的依賴而影響當前模塊的性能和可靠性，可適度保存其它模塊的關鍵數據，減少由於訪問其它模塊服務帶來的系統損耗和可靠性壓力。
-
使用NoSQL數據庫對海量大數據進行存儲和處理。
-
系統/網絡層面監控：主要是對下列指標進行監控：服務器指標，如CPU、內存、磁盤、流量、TCP連接數等；數據庫指標，如QPS、主從複製延時、進程、慢查詢等。
-
業務層面監控：通過在指定頁面做埋點，和從業務系統的數據庫兩種方法，將需要監控的數據抽取出來，做必要的分析處理，存入運維自己維護的數據庫中；然後通過瀏覽器頁面，展示監控數據，頁面同時提供各種時間維度上的篩選、彙總。對一些業務的關鍵指標如PV、UV、商品展示、登錄/註冊、轉化率、購物車、訂單數量、支付量、發貨量和各倉訂單數據。可自定義告警範圍，通知相關人以便做出響應。
-
應用層面監控系統Mercury：獨立研發應用性能監控平臺，通過在應用程序中植入探針邏輯來實現對應用代碼、關係數據庫、緩存系統的實時監控。Mercury通過收集日誌、上報日誌的方式即時獲取相關性能指標並進行智能分析，及時發現分佈式應用系統的性能問題以及異常和錯誤，爲系統解決性能和程序問題提供方便可靠的依據。同時通過Mercury數據展現平臺，用戶可輕鬆便捷的獲取應用360度監控信息。