redis的一些優化

以前記錄在公司內部的wiki上的,如今把這些經驗分享出來,固然這些優化,都已經在框架的底層作掉了,使用框架時,並不須要特別在乎

• hset/hsetnx和hmset的性能差異
  在註冊用戶的時候,以前咱們大量使用hsetnx,能夠保證用戶數據的惟一性,防止屢次寫入
  但通過測試,這種方式,相比hmset性能差異巨大,因此採起了下面的方式
  

• 存儲數據,某些狀況採用ziplist節省空間
  在作遊戲時,咱們大量使用redis的hash結構,但這種結構,雖然叫作hash,但當hash-max-ziplist-entries 512實用這個配置,數據key < 512條時,實際用的是ziplist,一種用binary作鏈表鏈接標識的壓縮鏈表,爲了節省存儲空間,畢竟hash結構要記錄的信息太多,空間換時間
  在優化以前,咱們的一個普通的角色信息,是相似這樣存儲的

  Key role:96

  Field 96

  Value [96,96,0,10,1,100]

一個role:96裏只有一個field(96),這樣實際上很是浪費空間,用一個完整的ziplist結構描述,但只存儲一個key
因此進行了優化,例如role:0這個key,存儲了512個field,進行了這樣的拆分後,即不會觸發閥值,將存儲結構變爲真正的hash table,也充分利用了ziplist的結構描述,大大節省了空間
一個簡單的配置:
$config['redis_cut_single_table'] = 512;

• hIncrBy使用方法優化
  在咱們一次請求,好比用戶道具的插入,這種時候,一次會須要生成不少的新id,這種狀況,這個優化就很是關鍵了
  減小hIncrBy方法的調用次數,採用php內部預生成分配的辦法,批量插入的時候將大量提高