-
CDN：Content Delivery Network，即内容分发网络。放置一些静态化资源，或者可以将动态数据分离，比如秒杀详情页，做成HTML放在cdn上，动态数据可以通过ajax请求后台获取。一些js依赖直接用公网的CDN，自己开发的一些页面也做静态化处理推送到CDN。用户在CDN获取到的数据不需要再访问我们的服务器，动静态分离可以降低服务器请求量。
WebServer一般不直接对外访问，之前都会放置Nginx，Nginx是一个集群化的，部署在多个服务器上，用来做我们的Http服务器，响应客户请求。同时他还会为后端的Tomcat，Jetty这些servlet容器来做反向代理，以达到负载均衡的效果。
Redis：做服务器端的缓存，利用Redis提供的API来达到热点数据的快速存取的过程。加速后台获取数据，减少数据库的请求量。
MySQL：借助MySQL的事务来达到秒杀的数据的一致性和完整性。
查看全部 -
11111
查看全部 -
Mark 调试代码
查看全部 -
更新库存的是热点操作，会出现行级锁，而插入购买记录的行为没有行级锁。可以先插入购买明细，可以避免因重复秒杀带来的不必要的更新库存操作，减少不必要的行级锁的占用。然后再去更新库存。代码中，根据热点商品竞争的结果，来决定下一步是rollback还是commit，降低了网络延迟和GC影响一半的时间
插入操作放在前面，插入操作就是把秒杀单，用户id，电话组成一个组件，这个组件冲突的概率并不是很高，因为秒杀单在前头，还有用户的电话，组成一个唯一键，这个时候的网络延迟和GC是可以并行的，这个时候再去拿update减库存的rowLocl行级锁
rowLock: 行级锁，锁的粒度最小，并发度最高，加锁慢
最终目的：降低MySQL roollock的持有时间
查看全部 -
回顾事务执行
秒杀操作通过mysql的事务来完成。
查看全部 -
详情页：做静态化放到CDN中，各个公司CDN不同，不细讲
系统时间部分：new了一个对象，很简单很快，不用优化
地址暴露接口（高并发点）: 不方便做成静态放到CDN中，需要放到服务器端，通过逻辑去控制；但是该接口调用频繁，不希望放到数据库中-->使用redis优化.
执行秒杀操作：高并发点
查看全部 -
优化：
前端： 动静态数据做分离，减少请求与响应时间；按钮防重复，防止用户发送无效的重复请求，因为秒杀活动一般都会有购买数量的限制，敲的次数再多，最后还是要查看是否已购。影响了效率，可有前端代为处理并优化
后端：使用CDN换存重要的静态资源等；在后端对活动结束时间、商品选购时间、业务的相关逻辑要求都放在后端代码中，并调用缓存来进行暂存，已减少对DB的直接操作，提高效率
1,前端控制触发次数，比如限制控制按钮的触发
2,使用CDN和缓存机制达到动静分离
3,减少行级锁和GC的时间，将食物控制在mysql中进行，比如存储过程
查看全部 -
方法一：成本高，大公司使用
方法二：放到服务器端完成，MySQL执行sql效率非常高
查看全部 -
99999
查看全部 -
异地机房延迟分析
实际在20ms左右
查看全部 -
同城机房延迟分析
查看全部 -
优化方向是：
查看全部 -
不是MySQL慢，也不是Java慢。而是Java和数据库通讯之间会有网络延迟/GC，这些时间也要加在事务的执行周期里面。而同一行的事务是串性化的。
第一个用户执行一次商品购买时，对DB的update减库存操作不是执行完就结束，后续还涉及到GC内存满了，等待自动回收过程中的网络响应的延迟问题；
除此之外，用户的每一次购买操作都是一个具体的事务，其中还涉及到了用户个人的购买明细，可理解为淘宝的已购买这一项，而这又是一个insert 的操作，执行完后又或许可能再一次出现GC进行内存的清理而导致延迟，直到反应过来后，继续执行后续的事务提交commit或者失败后的回滚rollback
而这时另一个用户的update 操作已经开始很久了超过了 4W分之一秒的理想时间，所以，实际秒杀项目中，需要对每一个用户的update时间，即行级锁的时间进行优化，因为，下一个用户还在等待，他后面或许还有一个它也在等待....哈士奇瞪着眼等着呢
查看全部 -
串行化操作
查看全部 -
压力测试下，一条update 可以 达到 4W 的 QPS ，等同于一件商品能在一秒内被销售掉 4W 件，这应该是理想值吧！
那么，对于实际执行中的低效是什么原因？这才是并发中要优化的重点吧！
查看全部
举报