rs勿忘初心的博客

具体的内容可以直接参考原文：搞懂异地多活，看这篇就够了 | Kaito's Blog下面是一些核心的点梳理：一、系统可用性一个好的软件架构应该遵循以下 3 个原则：高性能、高可用、易扩展。1、「高性能」意味着系统拥有更大流量的处理能力，更低的响应延迟。例如 1 秒可处理 10W 并发请求，接口响应时间 5 ms 等等。2、「易扩展」表示系统在迭代新功能时，能以最小的代价去扩展，系统遇到流量压力时，可以在不改动代码的前提下，去扩容系统。3、「高可用」这个概念，看起来很抽象，怎么理

一、SOA 和微服务对比开门见山，直接给出部分维度下SOA 和微服务的对比情况：接下来，详细从不同的对比维度说下SOA和微服务的特点：1、服务粒度整体上来说，SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个大型企业来说，“员工管理系统”就是一个 SOA 架构中的服务；而如果采用微服务架构，则“员工管理系统”会被拆分为更多的服务，比如“员工信息管理”“员工考勤管理”“员工假期管理”和“员工福利管理”等更多服务。2、服务通信SOA 采用了 ESB 作为服务间通信的

一、缓存的价值某些复杂的业务场景下，单靠存储系统的性能提升是远远不够的，比如：需要经过复杂的计算比如论坛首页展示用户同时在线数，MYSQL需要count(*)大量数据得到，此时无论怎么优化 MySQL，性能都不会太高，如果是实时展示的话，当用户数据量较大时，MySQL性能无法支撑。读多写少的数据，存储系统有心无力目前的互联网业务大多是读多写少的情况。例如微博、微信、淘宝等。读业务占了整体业务的90%以上。比如某个明星发了一条微博，可能有几千万人来看，写一条微博可能只需要一条insert语句，

关系型数据库由于其强大的 SQL 功能和 ACID 的属性，使得其在各式各样的系统中得到了广泛的应用，没有什么是"银弹"，关系型数据库同样也存在着一些问题，比如：关系数据库存储的是行记录，无法存储数据结构 关系数据库的 schema 扩展很不方便表结构 schema 是强约束，操作不存在的列会报错，业务变化时扩充列也比较麻烦，需要执行 DDL语句修改，而且修改时可能会长时间锁表（例如，MySQL 可能将表锁住 1 个小时）。关系数据库在大数据场景下 I/O 较高如果对一些大量数据的表进行统计之

读写分离分散了数据库读写操作的压力，但没有分散存储压力，当数据量达到千万甚至上亿条的时候，单台数据库服务器的存储能力会成为系统的瓶颈，主要体现在这几个方面：数据量太大，读写的性能会下降，即使有索引，索引也会变得很大，性能同样会下降。 数据文件会变得很大，数据库备份和恢复需要耗费很长时间。 数据文件越大，极端情况下丢失数据的风险越高（例如，机房火灾导致数据库主备机都发生故障）。基于上述原因，单个数据库服务器存储的数据量不能太大，需要控制在一定的范围内。为了满足业务数据存储的需求，就需要将存储分散到多

1.前言关系数据库由于其 ACID 的特性和功能强大的 SQL 查询，目前还是各种业务系统中关键和核心的存储系统，很多场景下高性能的设计最核心的部分就是关系数据库的设计。业务发展速度和数据增长速度，远远超出数据库厂商的优化速度，尤其是互联网业务兴起之后，海量用户加上海量数据的特点，单个数据库服务器已经难以满足业务需要，必须考虑数据库集群的方式来提升性能。高性能数据库集群的第一种方式是“读写分离”，其本质是将访问压力分散到集群中的多个节点，但是没有分散存储压力；第二种方式是“分库分表”，既可以分散