對於第壹個問題，設計壹個schema->(messageID，likedCount)，記錄每條微博的點贊數。messageID是微博的編號，likedCount是該微博的點贊人數。但是這裏有兩個問題需要解決，第壹是並發，第二是數據量。
每條微博都有可能有很多人同時點贊，為了保證點贊人數精確就需要保證likedCount是原子操作，這個可以由應用程序來實現，也可以用redis的事務來實現(如果redis有事務機制或者自增功能的話)，但是我覺得為了性能考慮，也可以不用實現原子操作，具體原因就不展開了。
每天都上億可能更多的微博內容產生，這樣就會有上億個新的(messageID，likedCount)生成，這樣的數據量是比較大的，單機數據庫比較難提供高效的服務，所以需要采取sharding的功能(有時候也叫分表分庫)，可能根據messageID把這些schema分散到十個或者更多的shards上(據說，sina微博有600個節點，如何三個節點組成壹個shard，就有200個shards)，這樣每個shard處理的請求就只有原來的十分之壹，從而就能提高服務的性能。
關於點贊人列表的設計，壹般來說，可能想到的schema是(messageID，userID)，但是這樣的設計有壹個小問題，就是有些大發的微博可能會得到幾十萬的點贊，這樣就會產生幾十萬個條數據，這樣數據有點多，讀取起來可能也慢。所以可以用這樣壹個schema(messageID，partID，userIDs)，讓壹個messageID對於多個userID，同時比對應太多的userID，所以加入壹個新的partID，壹個part存1000個userID，這樣幾十萬個點贊，只需要存幾百條數據。這樣做還有壹個好處，用戶點擊查看點贊人時的，壹般都不是完全顯示所有點贊人，而是壹批壹批顯示，這樣可以壹次只讀壹條數據，就可顯示壹批點贊用戶信息。