Redis存儲文章點擊量,string類型和hash類型用哪種比較好？

02-05

用hash類型的話，一個key就行了，但是隨著文章量增多field也一直增長，field過多達到一定的量後，會不會影響redis讀寫性能

用hash可以，但如果field很多的話，注意避免hgetall操作；如果知道文章的id，可以hmget 一批id這樣。

如果只是通過文章id進行點擊量的存取和自增操作的話，string涉及的操作有set,get和incr。hash涉及到的操作有hget，hset，hincr操作。這些操作的時間複雜度都是O(1)的，所以不用太擔心存取性能，反而大量string相較於hash來說要更加浪費內存，所以推薦使用hash。一次查詢多個文章id的話，hmget相對於mget也要有優勢（例如Jedis客戶端分片，多個節點的話，不同的key可能存放在不同的節點中，無法直接用mget，只能用管道查詢）。

不過如果只是以上這些操作的話，不明白題主為什麼要把訪問量單獨存儲到一個hash中，完全可以通過存成以文章為主體的結構，例如：

key = article:1

fields = like_count, view_count, comment_count

values = 10, 10, 10

如果真的必須將所有訪問量存放在同一個hash的話，有可能是為了方便持久化到資料庫。也就是先通過redis進行自增，然後定時將數據從redis同步到mysql中，避免mysql的並發和鎖問題。這樣的話就需要知道在這一時間段哪些文章的訪問量發生了改變，然後進行update的操作，才需要將訪問量和文章id單獨存放在hash中。例如：

key = view_count_hash

fields = article:1, article:2. article:3

values = 5, 10, 20

這時就需要想辦法避免在fields比較多的時候，hkeys佔用較長的時間，可以通過將用戶id取模分片，存儲在不同的hash中，或是減少同步的間隔時間，並在間隔後刪掉對應的fields。

如果題主不需要這樣做的話，還是建議分開存放在以文章為主體的結構中。

文章id按模存儲。例如%10，這樣就用10個hash就可以了；或者桶劃分——針對量大的情況

另外，文章的訪問量是否應該放在文章自身的屬性里更合適呢。

會還是不會不要靠猜，redis官網有對每種操作的時間複雜度的說明。看完就知道該選哪個了，別聽樓上的瞎扯。

推薦一個nodebb的開源項目，裡面用到了redis存儲點擊量，也許會有參考價值