一, 系统拆分
将一个系统拆分为多个子系统, 用 dubbo 来搞. 然后每个系统连一个数据库, 这样本来就一个库, 现在多个数据库, 不也可以扛高并发么.
二, 缓存
缓存, 必须得用缓存. 大部分的高并发场景, 都是读多写少, 那你完全可以在数据库和缓存里都写一份, 然后读的时候大量走缓存不就得了. 毕竟人家 Redis 轻轻松松单机几万的并发. 所以你可以考虑考虑你的项目里, 那些承载主要请求的读场景, 怎么用缓存来抗高并发.
三, MQ
MQ, 必须得用 MQ. 可能你还是会出现高并发写的场景, 比如说一个业务操作里要频繁搞数据库几十次, 增删改增删改, 疯了. 那高并发绝对搞挂你的系统, 你要是用 Redis 来承载写那肯定不行, 人家是缓存, 数据随时就被 LRU 了, 数据格式还无比简单, 没有事务支持. 所以该用 MySQL 还得用 MySQL 啊. 那你咋办? 用 MQ 吧, 大量的写请求灌入 MQ 里, 排队慢慢玩儿, 后边系统消费后慢慢写, 控制在 MySQL 承载范围之内. 所以你得考虑考虑你的项目里, 那些承载复杂写业务逻辑的场景里, 如何用 MQ 来异步写, 提升并发性. MQ 单机抗几万并发也是 ok 的, 这个之前还特意说过.
四, 分库分表
分库分表, 可能到了最后数据库层面还是免不了抗高并发的要求, 好吧, 那么就将一个数据库拆分为多个库, 多个库来扛更高的并发; 然后将一个表拆分为多个表, 每个表的数据量保持少一点, 提高 sql 跑的性能.
五, 读写分离
读写分离, 这个就是说大部分时候数据库可能也是读多写少, 没必要所有请求都集中在一个库上吧, 可以搞个主从架构, 主库写入, 从库读取, 搞一个读写分离. 读流量太多的时候, 还可以加更多的从库.
五, Elasticsearch
Elasticsearch, 简称 es.es 是分布式的, 可以随便扩容, 分布式天然就可以支撑高并发, 因为动不动就可以扩容加机器来扛更高的并发. 那么一些比较简单的查询, 统计类的操作, 可以考虑用 es 来承载, 还有一些全文搜索类的操作, 也可以考虑用 es 来承载.
上面的 6 点, 基本就是高并发系统肯定要干的一些事儿, 大家可以仔细结合之前讲过的知识考虑一下, 到时候你可以系统的把这块阐述一下, 然后每个部分要注意哪些问题, 之前都讲过了, 你都可以阐述阐述, 表明你对这块是有点积累的.
说句实话, 毕竟你真正厉害的一点, 不是在于弄明白一些技术, 或者大概知道一个高并发系统应该长什么样? 其实实际上在真正的复杂的业务系统里, 做高并发要远远比上面提到的点要复杂几十倍到上百倍. 你需要考虑: 哪些需要分库分表, 哪些不需要分库分表, 单库单表跟分库分表如何 join, 哪些数据要放到缓存里去, 放哪些数据再可以扛住高并发的请求, 你需要完成对一个复杂业务系统的分析之后, 然后逐步逐步的加入高并发的系统架构的改造, 这个过程是无比复杂的, 一旦做过一次, 并且做好了, 你在这个市场上就会非常的吃香.
其实大部分公司, 真正看重的, 不是说你掌握高并发相关的一些基本的架构知识, 架构中的一些技术, RocketMQ,Kafka,Redis,Elasticsearch, 高并发这一块, 你了解了, 也只能是次一等的人才. 对一个有几十万行代码的复杂的分布式系统, 一步一步架构, 设计以及实践过高并发架构的人, 这个经验是难能可贵的.
来源: http://www.bubuko.com/infodetail-3478763.html