肉眼品世界導讀：?在互聯網環境里，很多時候常常會有海量級別的訂單，高并發，低延遲，不同的業務場景有不同的做法。更多優質內容請關注微信公眾號“肉眼品世界”(ID：find_world_fine)業務場景

一交易系統，毫秒內就會產生一條交易數據，有付款方，收款方，交易類型，交易符號，分別為from ,to ,type,symbol,前面玩過一下apache?phoenix 來做sql查詢《從phoenix hbase談談研發管理和技術選型》,效率還是慢了點兒，還是原生的好

從業務需求來看主要有幾個點兒：

1：交易記錄實時寫入，實時查詢，支持交易記錄多條件查詢，還能分頁，這里條件剛好比較固定，就username(交易方),type,symbol

2: ?用戶的余額要實時返回,賬目可追溯

3: 海量交易數據

這里使用了hbase作為存儲介質，當然大家也可以嘗試一下tidb

數據落地

hbase寫入效率還是比較高的，但是太高有時會自動不讓寫入，寫入也是有一些參數需要優化調整的，多條件的復合查詢對于hbase來說有時真是有點兒XX，所以rowkey的設計特別關鍵，但是rowkey并不是萬能的

hbase寫入優化:

有很多參數優化的帖子，根據業務實際情況動態調整，這里就不一一列舉了，這里主要講一下rowkey和數據結構設計：

一：第一回合

String?rowkeyPrefix?=??from+"==="+to+"==="+type+"000$"+symbol+"000"+(MAXID-orderid)

hbase里每個rowkey字段位數需要保持一致，不足的用=或者其他字符補齊,用戶ID?from和to的ID倒轉,如13567變成76531，便于寫入數據散列到多個Region服務器上，還能保證同一個用戶是緊密挨著一起的，最后可以預見的最大訂單ID為999999999999999，具體多少個9根據你業務來定位數，MAXID-orderid作為訂單的唯一標記還能按時間，訂單先后順序排序，就用不著LONG.MAX_VALUE-timestamp了，查詢訂單詳情的時候還方便查詢，訂單數據都在一張表里

嘩啦啦，開始多線程批量偽造數據，PC單機每秒可達1500左右，很快數據就達到100W，通過username,type,symbol分頁查詢數據，呼啦啦，還是很快的，很高興，再繼續打數據，一千萬的時候，咋開始有點兒慢了，但也還是在一秒左后會返回，繼續再往后面打數據就會越來越慢，達到億級的時候就有點兒卡了，第因為查詢第一頁數據的時候是不知道startrow和endrow的，第二頁開始就可以傳startrow了，掃描范圍縮小，速度會快很多

這個時當我們去查詢單個訂單詳情的時候，以為訂單唯一數字id都在rowkey里面，還只是查詢一個數據會爆快的，結果確是慢，原因是唯一id放在了rowkey的最后，hbase會從前往后挨著掃描的，一個訂單的詳情往往是不會改變的，自然是可以加一層緩存的，速度快樂

但是分頁的數據在億級的時候，特別是第一頁就慢了，當然第一頁數據并不是很多，實時redis緩存第一頁用戶的數據，速度還是會比較快的，怎么實時更新呢，當新寫入數據的時候，把對應redis的第一頁列表數據也給更新了；交易詳情的redis 緩存key需要設置失效時間，不然過多的不用cache key呆內存也不是太好的

一般情況下，這樣的第一頁分頁數據用redis提供，用戶詳情用緩存提供，第二頁以上的分頁數據用startrow提供，機器稍微配置好些，在千萬至億級的數量級，已經夠用了

對于用戶金額的實時寫入更新，使用了redis increment的原子操作，實時自增，并落地到數據庫

二：第一回合

但是隨著數據量的越來越大，以及業務場景中用戶對于3，4秒乃至10多秒才能返回數據的情況的用戶體驗還是有一定影響的，雖然說第一頁或者用戶進來速度就是嘩嘩的，可以看起來很快，于是開始拆分

原先的一張hbase表拆分成兩張，一張表為order_record_index:rowkey值不變，只記錄訂單自增唯一id,相當于訂單索引ID

另外一張表為訂單詳情表order_detail,rowkey為訂單id

這樣設計的好處是什么呢，馬上就懂了

當查詢訂單詳情的時候，通過訂單id ，相當于是order_detail中的rowkey，hbase第一大特別，存儲海量大數據，還有一個非常突出的性能表現，那就是通過確定唯一的rowkey取值了，那是相當的快,這個時候獲取訂單詳情的時候就是刷刷的了，當然你要加一個有失效時間的緩存，那也是可以的，毫秒級的返回沒問題了

第二個，通過order_record_index這張表不存儲訂單的全部數據，只存儲訂單ID，數據量一下就下來了，再去查詢速度明顯快了很多，先通過rowkey找到訂單ID，在通過訂單ID批量通過order_detail rowkey獲得 交易數據詳情列表，但是這樣的情況下依然不能做到多條件下的分頁高效返回

三：第三回合

這個時候redis的有序集合就用上了，還是以索引ID的思路，hbase的兩張表結構不變，在redis集群中維護用戶的訂單id 列表,由于多條件組合查詢相對固定，zset集合的key值為:

String?cacheKey?=??from+to+type++symbol

redis的cachekey就沒有像hbase rowkey那樣補齊了，盡量節約空間，然后新增訂單數據的時候，實時刷新redis cachekey的用戶訂單id

redistemplate.opsforzset.add(cacheKey,Bytes.toBytes(order_id),order_id);

這里，value值為bytes，取出來的時候不需要循環再轉，直接批量通過hbase查詢，因為hbase的rowkey?是bytes的

分頁的時候怎么辦呢，更好用:

Object?o?=?redisTemplate.opsforzset.zrange(cachekey,(page-1)*pageSize,page*pageSize);

有同學會問，數據量那么大，redis分頁好用嘛，這個得結合業務場景來，總的訂單數據量很大，但是每個用戶的訂單數據量是有限的，那么根據單個用戶量去做zrange，效率自然沒問題，redis可以根據數據量做集群或者自己根據cachekey做hash,理論上是可以無限擴展的，這樣我們拿到該分頁數據的rowkey list后，直接去hbase order_detail表中批量抓取，刷的一下就出來了，充分利用了hbase rowkey查詢和redis zset分頁的效果

這個時候是不是就ok了呢，不是，萬一redis掛了怎么辦，你的列表數據都在redis里

這個時候會去hbase的order_record_index的索引表里獲取查詢，也就是redis還是輕量級的可持久化的緩存系統，數據落地還是需要在hbase中

當redis索引失效的時候，可以通過hbase中的索引id列表重建索引，可以單個用戶重建，也可以批量重建，因為是zset集合,批量重建并不會出現數據錯誤，訂單增加之類的情況

這樣，一個在海量數據的情況下，依然可以做到不到秒級的多條件下數據分頁數據返回

當然，你還可以嘗試elasticsearch構建索引，通過hbase查詢數據的方式構建

這里面也還有很多細節參數可以優化，隨著業務的發展不斷進化，歡迎留言討論完善

相關閱讀:

億級(無限級)并發，沒那么難

不是你需要中臺，而是一名合格的架構師(附各大廠中臺建設PPT)

如何成為一個騷氣的架構師,看這一篇就夠了

關于高大上的DDD，白話入門篇

后端，你再不懂vue就out了

總結

以上是生活随笔為你收集整理的uniapp返回上一页_一例万级写入并发，百亿级数据，毫秒级返回架构分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。