編輯｜小智
1 為什麼強調收銀系統的可用性？
隨著移動支付高速發展，使用者已養成出門消費不帶錢包的習慣， 頻繁的日常消費對商戶收銀系統高可用提出了極高的要求，收銀系統一點小小的故障如「付不了錢、重複支付、付款超時」等都會給使用者和商戶帶來諸多的不適和不利，引發使用者憤怒、投訴、糾紛，最終導致商戶的使用者流失。所以對於商戶來說如何打造高可用的收銀系統就變得十分的重要。
如何打造高可用收銀系統？看完本文，相信您將有所啟發。
2 高可用收銀系統設計方案
通過對市面上的收銀系統進行分析研究，發現普遍存在以下風險：
1.服務時延不穩定：
2.系統可用性考慮不周：
業務邏輯服務和資料服務部署在一起，相互影響；
無異地容災、自動切換能力；
3.資料容災恢復不及時：
1.降低服務時延：
收銀系統線下門店遍布全國、網路複雜（包含電信、聯通、鐵通、移動等），對系統時延提出更高挑戰。
針對這個問題，一些雲服務商支援「bgp網路訪問跨地域實時切換」的能力，通過冗餘網路出口部署，實現跨區域網路間靈活切換排程，為網路出口災備提供了保障。
注：雙網域名稱探測擇優有如下注意點：
併發探測，誰先回來誰先被採用，從而提公升效率；
建立探測重試機制、控制探測頻率，減少不必要的探測；
建議的探測時機：系統開啟時發起探測，或請求超時發起探測；
2.雲助力，低成本提公升可用性：
因素一、多地部署、多點接入：
因素二、防ddos攻擊：
因素三、負載均衡、故障遮蔽：
為了提公升系統的穩定性和容災能力，業界比較成熟的解決方案是基於「無狀態的應用層服務設計」，做到能夠「實時監控伺服器節點可用狀態、自動轉移失敗任務到其他可用節點、將集中請求分攤到集群各個機器節點的能力」。
clb 單集群4臺物理伺服器組成，最大併發連線數超過1.2億，可處理峰值40gbps的流量，每秒處理包量為600萬。只有一台例項可用的極端情況下，仍可支撐3000萬以上的併發連線，確保後端正常提供服務，高擴充套件和低成本的優勢最大限度節省it成本。
因素四、過載保護：
移動支付目前處於高速增長期，各種營銷活動會帶來業務高峰。
一方面需要及時擴容，預留冗餘服務能力；另一方面當實際業務流量遠超過系統的最大正常服務水平時進行自我保護，快速拒絕掉部分請求，保證正常的服務水平，而不是被拖垮影響全部服務；
建議採用雲服務商提供的訊息佇列，通過雲上的分布式訊息佇列cmq提供可靠的非同步通訊，有效提公升系統吞吐量，確保訊息的可靠傳遞，減少後端系統壓力，防止系統雪崩。
3.「跳單」，實現資料層秒級自動容災切換能力：
收銀系統的資料分成兩類，一類是訂單資訊（主要包括訂單表和退款表，特點是資料量大且多讀多寫）；另一類是基礎資訊（主要包含門店、裝置、商戶等資訊，特點是資料量少且多讀少寫）。這裡介紹的資料庫高效容災實踐是基於訂單資訊dｂ，以mysql為例。
mysql容災策略普遍依賴「半同步，主備切換」，通過自動或者人工切換（業務恢復時間在1分鐘到幾十分鐘之間）。這對於交易量稍大的場景來講，故障恢復時間還是太長。如何在更短的時間內達到恢復業務，我們設計了「跳單」的資料層容災解決方案。
核心思路：
在資料訪問層封裝乙個「跳單」元件「自動避開有故障的儲存」，讓訂單資料資料可以隨意落到各個容器。下面詳細介紹「跳單」的整體流程：
使用訂單號儲存分組標記，如原先單號為201609121215432322199，可以在最後一位加分組標識，如組2，則變成2016091212154323221992
在這樣的前提下：
a）建立訂單請求：
收銀終端的乙個建立訂單請求過來，先呼叫db選擇器隨機選擇一組db，然後查詢計數器，看該組db失敗次數是否超出閾值，超限則跳過重選，否則通過探測器傳送一條update語句，探測db是否可用。如失敗則需重選db，成功則把分組標記寫到單號，把訂單插入改組db。
b）更新或查詢請求：
直接解析單號的分組標記，然後操作對應db。「跳單」保證新交易是正常的，優先把支付做成。某組db發生故障時，訂單查詢和撤銷等操作需等主備切換恢復才能進行。
這裡的注意事項：
3 做了「跳單「後的日常演練
為檢測系統是否真正高可用，需要做定期演練，以下是我們的日常演練計畫：
每週做一次單組db故障的常規演練。
每季度做一次多組db故障演練。
從下圖演練時的監控可見，當某組db故障時請求會掉底發生跳單，但整體曲線平滑，業務執行正常，無影響。
擴容步驟：
部署新的訂單db，給它分配db編號；
將新庫資訊配置到db選擇元件；
新庫接入業務流量；
觀察監控有無異常；
縮容步驟：
將撤掉db的庫編號按收縮之後剩餘db數取模：例如原來有5組db，收縮到3組，計畫撤掉庫5，則先把5庫模3得到2。
把資料遷移到庫2，修改配置，關閉庫5流量。新的訂單不會再進入庫5，而歷史查詢則通過取模訪問庫2即可。
監控無異常之後正式撤掉庫5。
5 做了「跳單」後的商戶維度查詢
雖然因為「跳單」而帶來了列表查詢的效率問題，但是對收銀系統來說，核心設計理念還是「盡可能把支付做成」！不要因為列表查詢問題而影響到核心支付的可用性。
6 收銀系統安全性考慮
系統安全性也是衡量乙個收銀系統可用性的關鍵指標，通過調研發現線下收銀系統有可能存在以下安全風險：
收銀終端軟體被非法安裝；
整台pos機被盜；
中間人攻擊；
正常交易訂單被非法退款；
pos機註冊啟用機制，即解決收銀終端軟體被非法安裝的問題，又可以在pos機被盜時直接遮蔽掉；
請求及響應引數簽名機制，防止客戶端偽造，及請求篡改；
走https協議，且限制合法根證書，防止中間人抓包、監聽、請求重放；
綜上所述，從無到有搭建一套高可用收銀系統要考慮的問題點很多。全部自建成本不低，建議多關注雲服務商提供的一些基礎能力（bgp高防、bgp網路訪問跨地域實時切換、分布式訊息佇列cmq、負載均衡clb、彈性伸縮as、tdsql、「雲支付」等），盡可能站在雲時代的基礎設施上來進行高效研發才是更加明智的選擇。
再次強調，我們追求的是 「盡可能把支付做成」！
關於商戶運營開發組：
今日薦文
微信支付移動開發
chapter 8 3 文件中心 互動細節例如以下 步驟3 使用者確認收款方和金額。點選馬上支付後出現輸入password介面。可選擇零錢或銀行卡支付見圖8.3。圖8.3 使用者確認支付 圖8.4 支付成功提示頁面 下面專案開發環境以xcode10.0。執行環境為ios7.0為例，說明其開發中須要的...
微信支付 微信JSAPI支付
pay.php baby extend wx pay.php namespace wx class pay 通過redirecturi獲取授權資訊 return mixed public function getauthinfo 通過code換取網頁授權資訊 res this curlgetreq ...
微信支付JSAPI支付
這裡是報錯 下面是前端拿到資料後的一些操作 var jsapi ajax success function str function jsapicall function callpay else if document.attachevent else 把乙個官方sdk整合到thinkphp框架中...