为什么微信点赞会后移

这是因为微信的点赞功能是一个动态的功能，当你点赞时，它会把你的点赞记录放在一个叫做“点赞列表”的数据库里，然后在你的朋友圈里显示出来，但是这个点赞列表是有限的，所以当新的点赞进来的时候，可能会把老的点赞数据挤出去，导致点赞变得后移。

安装localStorage即可。

var paramJSON = {参数1:"值0"，参数2:"值1"}

//URL路径为你提交到后台录入数据库的 *** 作，也就是你的图片对应的路径

//paramJSON为你需要传递的参数 可选

//function回调函数为你点赞录入数据库后返回的消息，比如是否录入数据库成功等

$.post("URL路径", paramJSON,

function(data){

alert("Data Loaded: " + data)

})

对于第一个问题，设计一个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，这样几十万个点赞，只需要存几百条数据。这样做还有一个好处，用户点击查看点赞人时的，一般都不是完全显示所有点赞人，而是一批一批显示，这样可以一次只读一条数据，就可显示一批点赞用户信息。

---