如何做好架构设计

01、数据库架构应该怎么选

• 考虑业务场景的话，比如，缓存类型首推 redis、文档及日志首推 mongodb、关系型首推 mysql
• 考虑开发语言及技术栈的话，比如：java及python推荐mysql、.net推荐sqlserver
• 考虑数据量的话，比如：单表少于2000w推荐mysql等，超过5000w推荐sqlserver等，超过2亿推荐TiDB或Hbase等
• 考虑运维的话，核心交易系统则推荐传统集中式架构（架构简单但不支持横向扩展且影响面集中），而海量数据与高并发场景则推荐分布式架构（架构复杂但支持横向扩展且单点故障影响小）
• 考虑生态的话，首推 PostgreSQL（技术深度的“集大成者”）或 MySQL（存量市场的“实用主义”）
• 考虑信创要求的话，信创场景则推荐国产数据库，比如：TiDB 或 武汉达梦DM等
• 考虑成本的话，首推开源数据库（mysql或postgresql），毕竟免费嘛

02、高性能应用的多级缓存策略

• 在高并发应用中，缓存是提升系统性能和响应速度的关键组件。通过将频繁访问的数据暂存于高速存储介质中，缓存能够有效减少对后端数据源的访问次数，降低延迟，减轻数据库等持久化存储的压力。
• 通过多级缓存可以最大程度提高查询性能和并发，可参考下图：

03、慎用数据库的分库分表

分库分表，是为了解决传统数据库因为连接数不够、单表数据量太大而导致的吞吐量下降的一种有效手段，但是真的不建议无脑的使用，且不说分库分表的方案设计要考虑分表字段、分表算法以及全局ID的选择，还会带来跨表查询、跨库事务等问题，而且分库分表之后，基本上也就告别了分页查询和排序。当然这些问题，也都有解决办法，不过还是强烈建议不到万不得已，不要上分库分表，可以先尝试以下几个方案：

• 1、做好数据库的优化，单表2000w如果做好索引、减少多表join、适量的字段冗余，其实大多数情况下是能扛得住的
• 2、利用缓存减少对数据库的压力，把那些能够接受延迟或者变化频率比较低的数据放到分布式缓存或者本地缓存中
• 3、进行冷热数据的隔离，把那些更新和查询都不频繁的数据存放到历史库表或者离线数仓中，减少表中的数据量来提升效率
• 4、考虑数据库分区，分区之后数据存储在不同的表当中，可以减少单表的数据量，提升查询性能
• 5、考虑分布式数据库，将数据分散到多个节点上，提升性能和容量

04、如何设计日数据量超过10w的监控数据库架构

• 这里推荐使用 HBase，为了提高查询效率，将HBase分为历史库和实时库，实时库只保存1年以内的数据，而超过1年的数据则迁移到历史库，这样可以保证实时库的数据量是一个恒定的、可控的范围。
• 另外对于如此庞大的数据量，利用ID生成器并hash取模定位数据库节点的方案实现横向扩容。

05、百亿数据量的系统架构需要考虑哪些问题

当数据量达到10亿或百亿，系统架构需要考虑哪些问题？

• 1、选择什么样的数据库，用MySQL、Oracle还是HBase？
• 2、如何解决单点故障，用Zookeeper、MQ还是LVS？
• 3、如何保证数据的安全性，热备、冷备还是异地多活？
• 4、如何解决数据检索，用Atlas还是ES？
• 5、如何解决统计分析，离线统计还是实时统计

06、数据库瘦身方案

• 1、历史数据清理，删除一些历史或垃圾数据
• 2、冷热数据分离，针对大表，将历史数据（比如一年以前的数据）迁移到别的实例
• 3、架构调整，把图片或文件直接保存到分布式存储上，而非保存在数据库里面
• 4、库迁移，把其中几个库迁移别的实例上
• 5、分库，根据某个维度（比如订单id）做分库设计，比如拆分为16个分库到4个实例（每个实例4个分库）

07、架构设计要聚焦4张图

做架构设计，需要聚焦如下4张图，注意这4张图，自上而下是决定关系，自下向上是支撑关系，设计即是画图，画图即是设计

• 1、业务架构图：说清企业的战略、组织、功能、流程和价值
• 2、应用架构图：说清企业拆分为多少个系统、以及彼此之间的联系
• 3、数据架构图：说清企业的数据分类、分布和流转
• 4、技术架构图：说清企业用什么编程语言、开源框架、中间件和硬件