淘宝秒杀服务器架构猜想



了解了下memcached, 没想到除了可以缓存东西, 还可以利用他的带原子性特性的操作做并发控制.

以下假设淘宝秒杀场景

比如某商品10件物品待秒.

假设有100台web服务器(假设web服务器是Nginx + Tomcat),n台app服务器,n个数据库

前提: 假设有1千万用户访问, 之前看新闻说某游戏厂商1台服务器能支撑在线20万用户不是问题, 所以我猜web服务器瞬时10万请求应该没问题, 再加上淘宝的稀奇古怪的验证码, 请求也会分散在时间点后的数秒内.

1.第一步 如果Java层做过滤, 可以在每台web服务器servlet里或是业务处理模块里做个计数器AtomicInteger(10)等于待秒商品总数, decreaseAndGet()>=0的继续做后续处理, <0的直接返回秒杀结束页面.

或者Nginx源码增强改进, 可配某个特定的URL请求(验证码作为URL的一部分,或是验证POST中的数据), 只处理最先到达的正确的10个请求, 接下来的直接返回秒杀结束页面.

这样经过第一步的处理只剩下100台*10个=1000个请求.

2.第二步, memcached 里以商品id作为key的value放个10, 每个web 服务器在接到每个请求的同时, 向memcached服务器发起请求, 利用memcached的decr(key,1)操作返回值>=0的继续处理, 其余的返回秒杀失败页面.

这样经过第二步的处理只剩下100台中最快速到达的10个请求.

3.第三步, 向App服务器发起下单操作事务.

4.第四步, App服务器向商品所在的数据库请求减库存操作, (操作数据库时可以 “update table set count=count-1 where id=商品id and count>0;” update 成功记录数为1, 再向订单数据库添加订单记录, 都成功后提交整个事务, 否则的话提示秒杀失败. 用户进入支付流程.

你可能感兴趣的:(淘宝秒杀服务器架构猜想)