百万级并发架构 支撑日活百万用户的高并发系统，应该如何设计其数据库架构？ ？
支撑日活百万用户的高并发系统，应该如何设计其数据库架构？ ？
以MySQL为列：
1:要支持高并发系统，必须涉及事务，所以数据库引擎必须选择InnoDB。InnoDB支持事务，事务级别取决于业务。如果业务数据一致性要求非常高，事务将开启序列化级别，这将完全隔离事务，但会导致对锁资源的竞争加剧。MySQL的性能在一定程度上降低了。
2:数据库分为主数据库和从数据库。主数据库负责写入数据，集群数据库负责读取数据。注意主从数据库的数据一致性。
3:冷热数据分离，美团、饥饿部分设计采用冷热数据分离。以订单为例，出库单的主要业务场景是查询。数据查询越向前，概率越低。这是冷数据。正在交易的订单是热点数据，需要随时查询和更新。冷数据可以放入redis缓存。这将提高查询效率。
4：数据表设计，充分利用索引查询。businesssql避免返回无用的行和列，禁止使用select*query，在查询时增加限制，并尽可能返回满足要求的行。对于复杂的SQL，请考虑拆分SQL。拆分SQL有一个优点。对于重复查询SQL，将第二次查询放入MySQL缓冲区，避免重复磁盘操作，提高访问性能。
5：子数据库和子表。例如，业务数据按月份分类。在一定程度上，增加、删除、修改和检查的压力将得到缓解。
希望对您有所帮助。谢谢您。
有多少互联网系统确实需要使用分布式架构？
更不用说互联网的实际发展了，现在即使是面试新生，分布式的问题基本上都是不可避免的。
目前，分布式体系结构具有高并发性和高稳定性的特点。
高并发意味着当单节点服务器的性能达到瓶颈时，可以通过引入nginx和部署多个服务器节点来扩展，以增加系统的吞吐量。这就是1*n=n的意思。
高稳定性意味着，如果单个或部分节点由于不可预知的原因发生故障，则不会影响系统的整体功能服务，即M-N>0（M>N）。对于用户来说，系统可用性始终是最重要的。
综上所述，根据我个人的经验，目前无论是市场级产品还是公司级产品，只要项目团队有对服务质量的追求，他们都会以不同的方式向分布式架构发展。
另外，对于一个功能不是很复杂和庞大的项目组来说，只要在开发设计阶段一开始就及时引入Memcache或redis作为数据缓存，而不是使用服务器的内存，后期切换到分布式系统的过程就会非常快。
以上是我个人的观点。欢迎在下面的评论区与我交流。
我是苏思亮，来自bat的java开发工程师。我每天分享科技知识。欢迎您关注我，与我共同进步。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
