前言：有讚開始制定自己的技術規範，應邀請，筆者負責「快取使用規範」的制定，摘去部分保密內容，分享給大家。
根據谷歌的一項研究，假如乙個**在3秒鐘或更短時間內沒有載入成功，會有 53% 的手機使用者會離開。因此在提高應用程式的速度和效能上，每一毫秒都很重要，這直接影響了業務的留存率、轉化率。
大型**的特點有高併發、大流量、使用者分布廣泛、網路情況複雜等，快取正是系統優化的重要技術手段之一。它能夠降低系統延遲，緩解資料庫壓力，提高系統的整體可用性、併發性、可伸縮性等。
①讀多寫少的場景，如配置資訊、商品資訊、使用者資訊等。
②不追求資料強一致性的場景，大多數業務場景能接受短時間的不一致，但賬戶金額操作等重要資料的場景不建議使用。
即業務**圍繞著cache寫，是由業務**直接維護快取，一般使用這種方式。
多級快取，是指在整個系統架構的不同系統層級進行資料快取，以提公升訪問效率，這是應用最廣的方案之一。一般分為接入層快取、應用層快取，應用層快取又分為分布式快取、本地快取，本地快取一般又分為堆內快取、堆外快取、磁碟快取等。
接入網關層，可以使用openresty可以做一些快取前置的功能，查詢到快取結果後直接返回，無需走到應用層。
在商家大促場景下，極少數熱點資料可能造成伺服器壓力過大，導致伺服器效能、吞吐量、頻寬達到極限，出現響應慢或者拒絕服務的情況，這肯定是不允許的。常用的本地快取有：
有讚內部tmc元件提供了應用層熱點探測、本地快取等能力，可以直接接入。
建議直接使用kvds（有讚內部自研kv元件）
原有使用codis的業務，建議盡快遷移到kvds。
（1）key名設計
①可讀性；key命名需要方便管理，並防止衝突，建議採用風格「欄位1(應用):欄位2(業務):欄位3(特徵):primarykey」的格式進行命名。
示例：
account:user:info:***xx③不要包含特殊字元；如空格、換行、單雙引號以及其他轉義字元。②簡潔性；保證語義的前提下，控制key的長度，單詞較多時可以採用縮寫，當key較多時，記憶體占用也不容忽視。
（2）value設計
①選擇適合的資料型別。絕大部分場景string型別可以滿足，注意節省記憶體和效能之間的平衡。
②value值越小越好，建議不超過1kb。value越大，服務端能承受qps越低，請求耗時越大。當value大小超過1mb時，讀寫效能將嚴重受影響。string型別控制在10kb以內，hash、list、set、zset元素個數不要超過2000。
③value值較大的場景，建議參考下文」常見問題-bigkey「的方案進行優化。
（3）ttl
①快取場景必須設定ttl，保證命中率的前提下，越短越好。
②建議 ttl < 3小時，具體可結合業務場景設定。
（4）超時設定
普通kv介面：單key請求超時時間建議設定100ms左右，批量請求超時時間建議設定200ms以上。
特殊資料結構介面：超時時間建議設定500ms左右。
（5）超時處理
寫超時：理論上除非服務端壓力過大丟棄請求，否則所有寫請求在服務端都會執行成功，只是沒有返回結果給客戶端，除非業務邏輯依賴資料的強一致性，否則不需要重試，可以交由下乙個業務請求寫入快取。
讀超時：重試不要超過3次。
（6）命令使用
①o(n)命令關注n的數量；例如hgetall、lrange、smembers、zrange、sinter等並非不能使用，但是需要明確n的值。有遍歷的需求可以使用hscan、sscan、zscan代替。
②使用批量操作提高效率，例如mget、mset。注意控制一次批量操作的元素個數(例如100以內，實際也和元素位元組數有關)。
③合理使用select；redis的多資料庫較弱，使用數字進行區分，很多客戶端支援較差，同時多業務用多資料庫實際還是單執行緒處理，會有干擾。
④redis事務功能較弱，不建議使用；redis的事務功能較弱(不支援回滾)，而且要求一次事務操作的key必須在乙個slot上(可以使用hashtag功能解決)。
⑤禁止線上使用keys、flushall、flushdb等
一般只有查詢的操作才可以寫入快取，任何對資料修改的操作不要主動重新整理寫快取，而是刪除快取。具體的快取刪除、寫入機制可以根據業務特性進行調整，但一定要確保資料的一致性。
①review業務場景的使用姿勢是否合理，業務上有沒有優化的餘地。
②對value進行壓縮處理（壓縮後的大小能夠接受的情況下可以採用這種方案）。
③維度化快取，將value拆分為多個小value，按需獲取，客戶端再進行查詢、聚合。
④考慮使用多執行緒快取，如memcached來快取大value。（有讚kv是多執行緒，但同樣不建議使用大key，優先考慮上述的三種方式，避免大key）
如果業務場景可能存在快取訪問量過大造成熱點的場景，建議直接接入有讚內部tmc元件：
null值也存入快取。應用內部可以考慮構建乙個抽象的快取物件，資料不是直接儲存到快取，而是放入快取物件後再儲存進快取。
①雙重檢查鎖建立快取（根據業務場景，可以選擇分布式鎖，也可以考慮本地鎖）
③後台主動預刷入快取
①pass組會保障快取機器例項的高可用性。
②後台主動預熱刷入快取，如大促活動等需要預先給大商家刷入快取、過期前預刷取等。
③針對可能出現大量快取集中失效的場景，快取過期時間隨機打散。
mysql 使用規範 MySQL使用規範
一 表設計類 強制類規範 1.建立表的儲存引擎必須是innodb。2.每個表必須顯式的指定乙個主鍵。3.不允許使用聯合主鍵。4.不允許使用外來鍵。5.不允許存在和主鍵重複的索引。6.自增長字段必須是主鍵或唯一索引。7.不允許在資料庫中儲存諸如，影像之類的二進位制資料。8.不允許使用text型別字段 ...
mysql 使用規範 MySQL使用規範
mysql使用規範 一 核心規範 www.2cto.com 1.不用資料庫做運營，如md5 order by rand 2.控制單錶資料量 a 單錶純int不超過1000w b 單錶含char不超過500w c 單庫不超過300 400個表 3.表字段數少而精 a 影響因素 i.io高效 ii.全表...
mysql使用規範 MySQL使用規範 MySQL
bitscn.com mysql使用規範 一 核心規範 1.不用資料庫做運營，如md5 order by rand 2.控制單錶資料量 a 單錶純int不超過1000w b 單錶含char不超過500w c 單庫不超過300 400個表 3.表字段數少而精 a 影響因素 i.io高效 ii.全表遍歷...