redis一個對象能支持幾千萬個key么，讀寫會有什麼問題？

09-03

我是初學者，提一個目前遇到的業務場景的問題。
幾千萬用戶，要把用戶偏好的書籍類型（記為數據A）、用戶偏好的音樂類型（記為數據B）、用戶的年齡/性別等基礎信息（記為數據C）等等，放到redis里，前台程序查詢後做簡單的處理邏輯。這些數據每周或每月更新一次。
請問：

1.這種場景適合用redis實現么？目的是快速檢索，數據對象可能很多，上百個
2.一個對象（如A）的key就有幾千萬種，讀的時候是否有性能問題？這個數量級對redis來說算大還是小
3.數據的定期更新，寫的時候有什麼好的處理方式？
4.如何預估數據所需的容量

5.設計和開發過程中有哪些地方需要注意？我知道value不能大於512MB

1. Redis 只適合精確檢索，使用 keys 關鍵字做檢索的話一定會遍歷所有 key，如果不能得出精確的 key 就不能用 Redis。「數據對象可能很多，上百個」，不明白這句話的意思，對 Redis 來說「對象」只是字元串，你能做的也只是把對象序列化成字元串存儲到 Redis 中，取出來時反序列化成對象。

2. 只要有精確的 key，檢索時不會有任何性能問題。Redis 用於存儲 key 的是一個字典對象，查詢性能與數量級無關。

3. 用 pipeline 批量執行。

4. 數據量大部分取決於你使用的數據格式，也取決於你單個 key 的數據規模。比如使用 Hash 時，默認 entry 數量小於 512 時或 value 小於 64 Kb，使用 ziplist 作為數據結構存儲，否則使用 dict 作為數據結構存儲。一個 key 還可能產生一個 ttl 對象記錄過期時間。很難非常準確地預計。如果不用過分精確地估計的話，建議先放入一部分數據，通過「info」關鍵字查詢放入前後 memory 的大小來估算。

5. Redis 是近乎不可視的存儲工具，如果要做數據統計、模糊檢索，就不要用 Redis 。Redis 更適合用於快速存取的場景。

我覺得幾千萬個key, 如果影響查詢速度可以分成幾個redis來做就行了，不是什麼大問題，保證內存夠用就可以了

一個 mysql 就能搞定的事情，非把 redis 拉進來幹嘛。你需要每秒上千次讀寫么？