Redis在互聯(lián)網(wǎng)金融賬務(wù)核心系統(tǒng)中的應(yīng)用

1、 Redis 在互聯(lián)網(wǎng)金融賬務(wù)核心系統(tǒng)中的應(yīng)用 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66550643 Redis 在互聯(lián)網(wǎng)金融賬務(wù)核心系統(tǒng)中的應(yīng)用 PAGEREF _Toc66550643 h 1 HYPERLINK l _Toc66550644 1.Redis 的技術(shù)特性和演進 PAGEREF _Toc66550644 h 3 HYPERLINK l _Toc66550645 2.Redis在互聯(lián)網(wǎng)金融賬務(wù)核心系統(tǒng)的一些應(yīng)用場景 PAGEREF _Toc66550645 h 7 HYPERLINK l _Toc66550646 3.Redis使用中遇到的一

2、些問題 PAGEREF _Toc66550646 h 10 HYPERLINK l _Toc66550647 4.Redis的監(jiān)控 PAGEREF _Toc66550647 h 13 HYPERLINK l _Toc66550648 5.總結(jié) PAGEREF _Toc66550648 h 13Redis是一個作用于內(nèi)存的數(shù)據(jù)結(jié)構(gòu)存儲系統(tǒng)，它可以作為數(shù)據(jù)庫、緩存或者消息中間件，支持多種類型的數(shù)據(jù)結(jié)構(gòu)。與傳統(tǒng)金融系統(tǒng)相比，互聯(lián)網(wǎng)金融系統(tǒng)更多的側(cè)重系統(tǒng)的高并發(fā)訪問、海量數(shù)據(jù)的處理，又有傳統(tǒng)金融對數(shù)據(jù)處理的可靠性和連續(xù)性。賬務(wù)核心系統(tǒng)是互聯(lián)網(wǎng)金融系統(tǒng)中非常重要的一個系統(tǒng)，它承載金融業(yè)務(wù)的開展，批量處理

3、業(yè)務(wù)流水，進行賬務(wù)的核對，客戶貸款的期次、利息、罰息的計算，還款計劃的生成等重要功能。隨著金融業(yè)務(wù)越來越廣泛、客戶數(shù)越來越多、賬務(wù)數(shù)據(jù)趨于龐大，給賬務(wù)處理工作帶來極大的壓力，造成嚴重問題而致不能正常開展業(yè)務(wù)。本文主要介紹REDIS內(nèi)存數(shù)據(jù)庫集群的特性和在互聯(lián)網(wǎng)金融賬務(wù)核心系統(tǒng)中的應(yīng)用實踐以及問題的解決方案。1.Redis 的技術(shù)特性和演進Redis是一款開源的、網(wǎng)絡(luò)化的、基于內(nèi)存的、可進行數(shù)據(jù)持久化KEY-VALUE的存儲系統(tǒng)。Redis通過KEY映射VALUE的方式來建立字典來保存數(shù)據(jù)，支持多類型存儲包括STRING、LIST，SET，SORT SET和HASH等，可以在這些數(shù)據(jù)類型上做很多

4、原子性操作。Redis將數(shù)據(jù)存儲在內(nèi)存里面，而且它發(fā)送給Redis的命令請求不需要經(jīng)過典型的查詢分析器（PARSER）或查詢優(yōu)化器（OPTIMIZER）處理，所以Redis對自身存儲的數(shù)據(jù)執(zhí)行隨機讀寫的速度是非?？焖俚摹ｋS著互聯(lián)網(wǎng)時代的推進、大數(shù)據(jù)時代的到來，Redis的版本也經(jīng)過翻天覆地的變化。從鍵的過期時間逐步細化、實現(xiàn)增量復(fù)制到推出分布式集群Redis CLUSTER，LUA腳本的功能不斷增強，再到4.0版本支持MODULE，由此可見，Redis的發(fā)展更多的擁抱了數(shù)據(jù)處理的大潮。在這種背景下，如何應(yīng)對當下互聯(lián)網(wǎng)金融賬務(wù)核心應(yīng)用的高并發(fā)、海量數(shù)據(jù)快速計算、數(shù)據(jù)結(jié)果急速響應(yīng)的需求，Redis

5、的使用提供了較為出色的解決方案，通過將數(shù)據(jù)和請求分布到不同的節(jié)點，實現(xiàn)水平擴展和負載均衡，進而提供高并發(fā)數(shù)、數(shù)據(jù)吞吐量和快速響應(yīng)的能力。Redis集群方案目前主流有三種，主從、SENTINEL、CLUSTER，因SENTINEL是基于主從的延伸，在此我們僅對哨兵和CLUSTER進行分析。一、SENTINEL集群SENTINEL是REDIS2.6版本中推出高可用（HA）解決方案，當用Redis做MASTER-SLAVE的高可用方案時，MASTER不能提供服務(wù)，Redis自身不能實現(xiàn)自動主從切換，因此SENTINEL承擔了監(jiān)視器的功能。它能監(jiān)控多個MASTER-SALVE集群，并能夠選舉多個SAL

6、VE中的一個作為新的MASTER，其他的SALVE節(jié)點會將它所追隨的MASTER地址改為被提升為MASTER的SALVE的新地址，拓撲圖如下。SENTINEL集群數(shù)據(jù)同步原理還是延續(xù)主從模式:（1）當從節(jié)點向主節(jié)點發(fā)送SYNC命令；（2）主節(jié)點接收命令后執(zhí)行BGSAVE命令保存快照，并創(chuàng)建持久化文件，同時將創(chuàng)建持久化文件期間的命令緩存；（3）主節(jié)點執(zhí)行完BGSAVE命令后，將持久化文件發(fā)送至從節(jié)點；（4）從節(jié)點接收持久化文件后開始接收主節(jié)點的命令緩存；（5）以上步驟均完成后，主節(jié)點每執(zhí)行一個寫入操作，均發(fā)送從節(jié)點。具體流程圖如下：二、CLUSTER集群CLUSTER集群是REDIS3.0版本中

7、推出的特性，是基于Redis的一個分布式實現(xiàn)。它引入了哈希槽的概念，支持動態(tài)添加或刪除節(jié)點，可線性擴展至1000個節(jié)點，多個Redis節(jié)點之間數(shù)據(jù)共享，部分節(jié)點不可達時集群仍可用，數(shù)據(jù)通過異步復(fù)制，不保證數(shù)據(jù)的強一致性，具備自動FAILOVER的能力，客戶端直接連接Redis SERVER，免去PROXY性能的消耗。Redis CLUSTER是一種去中心化的結(jié)構(gòu)，拓撲圖如下圖所示。所有節(jié)點之間互相連接，通過GOSSIP協(xié)議來發(fā)布廣播消息，每間隔時間內(nèi)互相發(fā)送PING/PONG心跳包來檢測其他節(jié)點狀態(tài)，來保持信息同步，客戶端直接連接任意Redis SERVER，并由Redis CLUSTER路由

8、轉(zhuǎn)發(fā)客戶端請求到真正請求數(shù)據(jù)的節(jié)點。CLUSTER集群數(shù)據(jù)同步原理還是延續(xù)主從模式，在此就不再重復(fù)的描述，在此著重說明一下CLUSTER集群的路由原理。當操作某個KEY時，Redis CLUSTER節(jié)點并不是采取代理的模式直接尋找到這個KEY所在的節(jié)點并執(zhí)行命令，而是將客戶端重定向到存儲這個KEY的節(jié)點，通過對KEY的操作，客戶端會記錄路由地址，最終客戶端獲得每個節(jié)點負責的KEY最新信息。在此同樣以流程圖來簡單描述。所以在一般情況下，對于給定的操作，客戶端會直接連接正確的節(jié)點并執(zhí)行命令。與單點Redis不一樣的是，CLUSTER集群引入了哈希槽概念，而且不是一致性哈希來實現(xiàn)，共有16384個哈

9、希槽。每個MASTER節(jié)點只負責一部分哈希槽，每個KEY通過HASH_SOLT=CRC16(KEY)%16384來計算屬于哪一個節(jié)點。三、總結(jié)我們先看下兩種集群方式在技術(shù)指標上的區(qū)別針對技術(shù)指標的側(cè)重點，SENTINEL模式更偏向于高可用的CACHE、存儲場景；CLUSTER模式用戶高可用的需求場景，更偏向于數(shù)據(jù)量較高的高可用CACHE、存儲場景。因此，在互聯(lián)網(wǎng)金融賬務(wù)核心系統(tǒng)中，更偏向于選擇REDIS CLUSTER。2.Redis在互聯(lián)網(wǎng)金融賬務(wù)核心系統(tǒng)的一些應(yīng)用場景互聯(lián)網(wǎng)金融賬務(wù)核心系統(tǒng)是一種特殊的賬務(wù)系統(tǒng)，與傳統(tǒng)金融的賬務(wù)核心相比較，它具備數(shù)據(jù)的強一致性和業(yè)務(wù)耦合程度，具備數(shù)據(jù)傳輸?shù)暮?/p>

10、規(guī)性，更具備某些場景下極高的訪問密集度。以下列舉Redis在互聯(lián)網(wǎng)金融賬務(wù)核心系統(tǒng)的一些典型的應(yīng)用場景。一、SESSION共享SESSION是一種記錄客戶狀態(tài)的機制，不同于COOKIE保存在客戶端瀏覽器中，SESSION是保存在服務(wù)器上?？蛻舳藶g覽器訪問服務(wù)器的時候，服務(wù)器把客戶端信息以某種形式記錄在服務(wù)器上，這就是SESSION，當客戶端和服務(wù)器需要再次交互時，只需要從該SESSION中查找該客戶的狀態(tài)就可以了。如下圖所示，用戶請求首先會到達負載均衡，負載均衡會根據(jù)路由策略將請求分發(fā)到后端的服務(wù)實例，這就會出現(xiàn)第一次的請求交給實例M，下次的請求可能會是實例N，如果不做SESSION共享，到達

11、實例N的請求會返回至客戶端進行處理。SESSION在多個服務(wù)和服務(wù)器之間共享，可多站點單點登錄，也可實現(xiàn)單點登錄的踢出功能。二、活動搶券活動搶券是互聯(lián)網(wǎng)金融公司最常用的營銷手段，對于互聯(lián)網(wǎng)金融公司來說，本業(yè)務(wù)場景帶來了幾個需要解決的問題，系統(tǒng)的高并發(fā)壓力；大量用戶搶同一張優(yōu)惠券帶來數(shù)據(jù)一致性問題；券不能超發(fā)、重復(fù)發(fā)；由于券涉及到資金，也帶資金安全的問題。由此可見，本場景主要的技術(shù)挑戰(zhàn)是高并發(fā)、高響應(yīng)、一致性、安全性等。我們引用了電力行業(yè)的一種措施“削峰填谷”，顧名思義，就是在流量洪峰到來之前在系統(tǒng)負載較低的時候進行冷熱數(shù)據(jù)的交換，和券數(shù)據(jù)的預(yù)熱，用來分擔領(lǐng)券活動后的高并發(fā)流量。而領(lǐng)券銷售活動的

12、業(yè)務(wù)特點是定時的洪峰流量對關(guān)聯(lián)系統(tǒng)造成的巨大的并發(fā)訪問的沖擊。在此，從業(yè)務(wù)場景來說，如下圖所示。（1）提前把訪問量蓄水，預(yù)熱活躍用戶，降低活動開始后的登錄和風控壓力。（2）對Redis進行全局數(shù)據(jù)化處理，基于Redis內(nèi)存高讀寫高QPS的特性，解決熱點數(shù)據(jù)的高并發(fā)問題。熱點數(shù)據(jù)均存儲在內(nèi)存中，采取Redis CLUSTER特性，進行多分片部署，通過高并發(fā)讀寫特性，提升系統(tǒng)吞吐量。下圖為熱數(shù)據(jù)的結(jié)構(gòu)和場景描述。（3）分布式鎖的應(yīng)用，在搶券過程中，可能出現(xiàn)多個用戶同時在搶同一張券，或同一用戶搶多張券的問題。當用戶點擊過快時，可能同一用戶的兩個線程同時通過了搶券資格的校驗，在這種情況下該用戶可以同時

13、搶兩張券。針對這個問題，我們通過對券號碼、用戶賬號兩個維度進行加分布式鎖來解決。根據(jù)REDIS的鎖服務(wù)設(shè)計，鎖在數(shù)據(jù)結(jié)構(gòu)中使用REDIS最簡單的KEY，核心在于建立鎖和釋放鎖，并保證絕對的安全。最簡單的方法是用GET來檢查鎖，當獲取不到信息，用SET來設(shè)置鎖。這種方式最簡單，但應(yīng)用場景較為局限，不能保證獨占鎖，因為在高并發(fā)場景中，GET和SET之間的毫秒級延遲，不能確保其他線程去進行GET和SET操作。針對這種風險，我們的鎖設(shè)計考慮使用SET NX PX來實現(xiàn)，如下：SET KEY 唯一隨機數(shù)值 NX PX 固定毫秒。設(shè)置KEY的值，僅在不存在時生效，并設(shè)置存活期為一個固定毫秒。和KEY關(guān)聯(lián)的

14、VALUE值在所有客戶端和所有加鎖請求中必須是唯一的。使用唯一隨機值是為了更安全的釋放鎖，刪除KEY值要增加邏輯且前置條件為KEY值存在和VALUE值是線程對應(yīng)的那個唯一值。具體加鎖實現(xiàn)方式如下。三、支付渠道限額本場景是支付路由場景下支付渠道限額的設(shè)計，是為了通過執(zhí)行渠道路由支付時，避免資金不足時缺乏渠道控制，造成大量交易失敗，導(dǎo)致處理異常。以下為路由示例圖。例如渠道A路由比例為70%、渠道B路由比例為30%，當支付請求過多時，渠道A的資金配額用盡會導(dǎo)致經(jīng)過渠道A的支付交易失敗，因此需要對配額進行計算，恢復(fù)配額金額?；诮灰讛?shù)據(jù)的強一致性和準確性，我們采取Redis命令的原子特性，即一個事務(wù)中

15、的所有操作，要么全部完成，要么全部不完成，不會結(jié)束在中間某個環(huán)節(jié)。具體的運算規(guī)范如下。3.Redis使用中遇到的一些問題在海量數(shù)據(jù)、高并發(fā)場景中，如何使用好Redis，約束KEY規(guī)范、合理確定VALUE值大??；合理設(shè)定參數(shù)大小，如TIMEOUT、MASMEMORY、MAXCILENT；合理分配緩存失效時間；合理加鎖控制分布式單線程數(shù)據(jù)庫查詢寫緩存操作等。在此，闡述在海量數(shù)據(jù)、高并發(fā)場景中遇到的一些問題。一、大VALUE問題背景：某時間點業(yè)務(wù)監(jiān)控大量告警，經(jīng)過排查，業(yè)務(wù)系統(tǒng)連接Redis報大量的TOO MANY CLUSTER REDIRECTIONS。經(jīng)過排查，發(fā)現(xiàn)業(yè)務(wù)系統(tǒng)連接REDIS異常，

16、同時網(wǎng)絡(luò)吞吐量異常洶涌。經(jīng)過查看源碼發(fā)現(xiàn)，當發(fā)生JEDISCONNECTIONEXCEPTION或者JEDISREDIRECTIONEXCEPTION時，會拋出此類異常，那我們著重分析下兩種異常的場景。JEDISCONNECTIONEXCEPTION顧名思義，連接REDIS錯誤，連接節(jié)點1時候FAILED，嘗試連接節(jié)點2仍舊FAILED，客戶端會推斷整個集群FAILD拋出異常，中斷當前連接。JEDISREDIRECTIONEXCEPTION的產(chǎn)生由于兩個異常產(chǎn)生，一個是MOVED導(dǎo)致，另一個是ASK導(dǎo)致，由此推斷，MOVED是節(jié)點發(fā)生遷移引發(fā)的哈希槽不能識別，而且ASK則是某一個槽被設(shè)置為IM

17、PORTING狀態(tài)時，節(jié)點在接收到ASKING命令后才會接收關(guān)于這個槽的命令請求。對Redis的內(nèi)部排查，內(nèi)部節(jié)點連接沒有異常，CLUSTER INFO狀態(tài)也是OK?；谝陨戏治龅贸鼋Y(jié)論，可能導(dǎo)致異常的場景為主從節(jié)點發(fā)生切換、遷移，網(wǎng)絡(luò)因素導(dǎo)致更新槽位信息失敗。驗證了我們發(fā)現(xiàn)Redis主節(jié)點的網(wǎng)卡流量巨大，已經(jīng)達到千兆網(wǎng)卡的最高值。于是我們查看了Redis慢查詢?nèi)罩?，發(fā)現(xiàn)頻繁調(diào)用某個KEY，而這個KEY存在大VALUE的問題，所以造成以上故障。解決方式為業(yè)務(wù)邏輯進行修改，修改后解決問題。二、緩存雪崩背景：某時間點業(yè)務(wù)監(jiān)控大量告警，鏈路耗時增加，數(shù)據(jù)庫CPU飆升。我們的緩存數(shù)據(jù)交換邏輯圖如下經(jīng)過

18、排查，發(fā)現(xiàn)數(shù)據(jù)庫CPU飆升因為查詢量激增，按照我們的數(shù)據(jù)交換邏輯來看，當客戶端請求在Redis命中直接返回，如果MISS才去數(shù)據(jù)庫查詢，查詢結(jié)果返回的同時將數(shù)據(jù)回寫至Redis。數(shù)據(jù)庫查詢量在業(yè)務(wù)沒有激增的情況下激增明顯是異?，F(xiàn)象，我們又排查了Redis的MONITOR記錄，發(fā)現(xiàn)所有的查詢都是MISS，存在階段時間內(nèi)請求擊穿的現(xiàn)象，所以造成了緩存雪崩。以上證據(jù)標明Redis本身是沒有問題，那有問題的只是代碼邏輯出現(xiàn)了異常。于是進行業(yè)務(wù)代碼的排查，發(fā)現(xiàn)設(shè)置KEY失效時間時候沒有進行校驗，導(dǎo)致所有的KEY在同一時間失效，進而請求全部轉(zhuǎn)向數(shù)據(jù)庫，導(dǎo)致緩存的雪崩。解決方式有兩種:（1）在緩存失效后，通

19、過隊列或者鎖機制來控制訪問數(shù)據(jù)庫和緩存的線程數(shù)量，這也是一種簡單的流控方式；（2）超時時間增加校驗標簽，二次判斷是否超時，如超時進行數(shù)據(jù)交換，由REDIS主動超時變?yōu)樽儎映瑫r。三、BGREWRITEAOF背景：收到告警，REDIS服務(wù)器磁盤空間不足。眾所周知，Redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)均是緩存在內(nèi)存中，唯一涉及磁盤的那就是持久化文件。順著思路看，果不其然，存放持久化文件的磁盤已逼近水線，且持久化文件的大小是占用內(nèi)存大小的三倍。官網(wǎng)上對BGREWRITEAOF是這樣解釋的，Redis BGREWRITEAOF命令用于異步執(zhí)行一個AOF（APPENDONLY FILE） 文件重寫操作。重寫會創(chuàng)建一個當前 AOF 文件的體積優(yōu)化版本。即使 BGREWRITEAOF 執(zhí)行失敗，也不會有任何數(shù)據(jù)丟失，因為舊的 AOF 文件在 BGREWRITEAOF 成功之前不會被修改。簡單來說，Redis的AOF機制類似于MYSQL的BINLOG，它會將所寫的命令按照一定的