|
有个帖子说了，太长了另起一楼。大部分的观点都是“硬碰硬”，其实没有必要，如果仅仅是秒杀，我觉得没有那么复杂。
系统架构：
秒杀程序实现：
关键点：
将事务分开，在应用层的事务并不严格，可以快速的处理大量并发，不需要db，也需要网络cache，唯一的操作就是本机内存操作，效率肯定非常高。
应用成功后，在将事务发到DB，这个时候可能由于并发会出现多拍的用户，再由DB过滤一遍，确保不会多拍。
唯一的缺点是事务到DB的同步过程有延迟，这是很快的，毫秒级。所以让（可能拍成功的）用户等两秒，用户应该可以接受。
性能分析：
应用层：基本没有代价，就看服务器处理连接的效率了，程序上只是一个计数器。如果觉得计数器是同步的会慢，就换成普通的int变量，多放几个“可能成功”的买家到 DB层过滤。假设1台机器1秒钟处理2000个请求应该问题不大吧。再假设网友会在60秒内提交完请求（由于时间不一致，很多网友的时钟不一定非常准确），一个服务器也能抗下12万用户。就算1千万网友参加，100台机器也足够了。
如果像taobao的博客所言的在处理100k并发技术，1台机器1秒钟处理10万用户，60秒就能处理600万。1千万并发也不过2台机器的事情。
数据库：数据库的并发来自有多少台应用服务器，应用服务器允许多少“可能买家”通过， 而不是有多少买家来秒杀。如果按照有些网友已经提到的，在机器中提前分配好，比如5台ipad，1台机器1台，其他机器直接报没有。那么DB的压力也就5台机器，可能传入的50个可能买家？计算时间上，也只需要2秒内算完就行了。
欢迎讨论。
|
|
|
