feed与秒杀，撑住10Wqps，架构方案一样吗？

《并发扣款，如何保证一致性？》一文，描述了高并发情况下，并发扣款的一致性，幂等性，以及ABA问题。

很有朋友有疑问：如果存在一个大客户，这一个客户并发量就非常高，版本号比对会导致大量的更新失败。于是推出，这个方案不适用于高并发场景。

究竟是不是这样呢？大家对高并发是不是有什么误解呢？

我经常说，任何脱离业务场景的架构设计都是耍流氓，今天来聊一聊三个高并发业务场景的架构设计差异。

一、QQ

QQ的一些核心业务有：

• 个人：user(uid, user_info, …)

• 好友：user_friends(uid, friend_id, …)

• 加入的群：user_groups(uid, group_id, …)

• 群：group(gid, group_info, …)

• 群成员：group_members(gid, uid, …)

• 个人消息：msgs_user(msg_id, uid, …)

• 群消息：msgs_group(msg_id, gid, …)

这些信息的读写有一个特点，都会带上uid/gid/msgid属性。

例如，拉取好友列表：

select friend_id from user_friends 

where uid=$uid;

在用户量很大，并发量很大时，不同用户/群/消息数据的读写并没有锁冲突。

画外音：10W个用户同时读写，彼此没有锁冲突。

只有当，同一个用户，很短的时间内，有大量并发时，才可能存在锁冲突。

画外音：例如，1个用户，1秒钟读写1W次。

这类场景下，使用《并发扣款，如何保证一致性？》中的CAS乐观来解决同一个用户的并发冲突一致性，是绝对没有问题的。

二、微博

微博的核心业务是feed流：

• 发消息，写操作

• 刷消息，读操作

微博业务显然是读多写少的，在用户刷消息时，自己feed流里的消息，是由别人发出的。

查看自己主页feed流，最朴