Social circle Data Structure design (Redis implementation)

1.player_simple_info pid Pid|level|profile_url|name----------------Hash
2.player_detail_info:12345 PID 12345 name Kaka guild_id 123 Visit_count 100000 gift_count the greatest man--------- --------Hash
3.player_friend_list:12345 pid1 pid2 pid3--------------------------Set
4.player_fan_list:12345 pid1 pid2 pid3------------------------Set
5.player_active_info pid1 time1 pid2 time2-----------------------Hash
4.msg_info:mid 12345|time|msg----------------------String
5.msg_list:12345 time1 mid1 time2 mid2------------------sorted set Pull messages, you can pull the page, and then mget msg info. Pull the PID to each message, then Hmget player simple Info
6.feed_info:fid 12345|comment_count|like_count|content--------------------string FID self-increment generation
7.feed_self_list:12345 time1 fid1 time2 fid2-------------sorted set player's own feed needs to push_back a feed ID, this feed list as a pull mode generation F Eed_show_list
8.feed_show_list:12345 10002 10002 10003 10003-------------sorted set pull feed, can be paged, first pulled to the FID list, and then Mget Feed_info
9.feed_like_list:fid time PID--------------sorted set Zadd feed_like_list:fid 1422222222 12345, the efficiency of adding and deleting is higher
10.feed_comment_list:fid time1 cid1 time2 cid2 time3 cid3-------------------------sorted set can be paged, mget time is 18619200 00 In addition to the highest bit, 861920000 * 100, if you reply to this comment, Time11 is time1+1
11.feed_comment_info:cid pid|time|for_fid/for_cid|target_id|content-------String comment to identify whether to comment on the feed or to reply to a comment, A comment on a message is just a comment on a feed, followed by a previous comment
Sharding strategy: 1.player_detail_info The largest amount of data, and there is no mget operation, so it is suitable for sharding
2.player_simple_info in the MSG list or the Feed list needs to be shown, so there will be a lot of mget operations, if done sharding, a player's friends or be concerned about may involve multiple DB query operations, efficiency will be reduced At the same time, simple info has a small amount of data and is more controllable.
3.msg_id to be through self-hyperplasia, MSG to set the expiration time, pull msg_list only get one months of data, for outside data, can be deleted in idle; Pull time page pull
4.feed_id to through self-proliferation, feed also to set the expiration time, their own feed feed_self_list in, their own space of the latest feed to pull from feed_show_list. 1) Player A sends a feed, need simultaneously zadd feed_self_list:a and FEED_SHOW_LIST:A 2) player sends a feed, pulls player_fan_list, from player_active_  Info Hmget The active time of each player to the recently active player (e.g. 12345), then zadd FID to feed_show_list:12345--------push mode respectively
5. Check Player A's homepage feed information to see if the feed_show_list:a exists, if there is a direct paging pull, if not, will collect the first 30 of each friend (including himself) Feed_self_list, and then push to Feed_show_ list, set the expiration time for feed_show_list to 1 days, then page pull
6. Regular cleanup of historical data, such as players without friends, Msg_info and feed_info to do expire, while Msg_list and feed_list to delete unwanted historical data
Master has three instances: 1.detail_info_db do sharding 2.simple_info do not do sharding, you can do slave cascade 3.msg_feed do sharding, you can do slave cascade
Msg_feed write in master, the query can be in any slave