现在很多公司的招聘信息，都会有这这么一条要求：有分布式、高并发、高负载、高可用系统设计、开发和调优经验者优先；
写这个岗位描述的HR，恨不得把自己知道的所有看上去高大上的词全都堆砌上。恨不得让别人一看就会认为这是一家巨牛X的公司。
一提到高并发、分布式、高可用这些词，很多人都会不自然的想到新闻里阿里双11每秒创建几十万笔的交易订单（2019双11订单创建峰值创纪录每秒54.4万笔）。
其实，高并发并不神秘，说白了就是想办法搞定两个指标：提升QPS、降低RT。并且同时保证数据的正确性、系统的可用性就OK了。
1、网站并发量上来了？啥都不要管，先扩容，堆机器。机器多了自然需要集群技术、负载均衡了。（提升QPS）
2、机器多了也扛不住了？服务拆分，把集中式部署改成分布式部署。（提升QPS）
3、分布式了还是扛不住？先做降级，再做限流。（保证系统可用性）
4、数据库扛不住了？上分布式缓存。（降低RT）
5、缓存上了之后，数据还是扛不住？那就考虑读写分离、分库分表、数据库容灾。
6、系统间同步交互有延迟？解耦，上异步方案，采用消息中间件。（降低RT）
7、高并发导致了脏数据？上分布式锁。（保证数据正确性）
8、高并发导致了数据不一致？上分布式事务。（保证数据正确性）
架构从来不是设计出来的，是演进出来的。不要不设计，也不要过度设计。系统流量上来了，先直接扩容而不是上来就搞很复杂的架构。
就算是再牛X的架构，使用了再先进的技术，阿里巴巴也不能靠几十台机器就抗的住双十一！
遇到啥解决啥，在解决问题的时候，再想着尽量把架构做的漂亮一点。在系统架构迭代过程中，自然会遇到各种新问题，那就解决新问题就好了！
原文地址：别扯了，这才是应对高并发的正确处理思路
一勺红糖，加一勺蜂蜜 搅拌均匀，涂在脸上按摩5分钟，静置10分钟，3天让你脸上容光焕发 -->生活小窍门
声明：禁止任何非法用途使用，凡因违规使用而引起的任何法律纠纷，本站概不负责。
精彩评论