本文参考58沈剑《架构师之路》,看完思路逐渐清晰,但是文章我也会进行一些补充,我的文章都是遇到一个问题解决一个问题,没有这样总体的思考过.redis,mq这些东西不是为了用而用,而是有一定的方向,要不就会产生一系列问题.
1 高并发为什么难做
例如抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存。读写冲突,锁非常严重,这是秒杀业务难的地方。那我们怎么优化高并发业务的架构呢?
2 优化方向
(1)将请求尽量拦截在系统上游
因为数据库历史残留问题,实际上刚开始是并发很少的,因为互联网不断发展,数据库其实并发量并不大.如果一下子打过来,而且还牵扯到锁,请求就会很慢或者超时,基本上体验感会很差.
(2)利用缓存
因为缓存是数据库上面的一层保障,用来抗并发,没有缓存直接打在数据
(3)合理设计缓存队列
(4)