Redis 与分布式架构入门：从单机到微服务的演进之路

若单台应用服务器无法满足需求，就需要引入负载均衡技术。负载均衡器（如 Nginx、LVS、F5）负责流量分发，不仅限于应用层，也可能涉及网络层（如 NAT 技术）。

用户的请求先到达负载均衡器，然后被分发到对应的应用服务器。可以理解为：负载均衡器是分配工作的领导，应用服务器是执行任务的组员。如果请求量大到负载均衡器也扛不住，只能增加负载均衡服务器，但这会增加成本。

数据库读写分离

即使做了负载均衡，如果频繁访问同一个数据库（读远多于写），压力依然很大。此时采取主从分离操作：一个主库负责写入并同步到多个从库，多个从库供读取。

应用中需要对读写请求做分离处理，可利用数据库中间件（如 MyCat、TDDL、Amoeba、Cobar）托管职责。

缓存机制与分库分表

热点数据指读取频率远高于其他的数据，冷数据则是不常访问的。为缓解压力，引入本地缓存或分布式缓存拦截用户请求，避免直连数据库。

例如商品网站，将商品信息等常见信息放在缓存中，交易界面等不常见信息放在库里。使用 Memcached 作为本地缓存，Redis 作为分布式缓存时，还需考虑缓存一致性、穿透、击穿、雪崩及热点数据集中失效等问题。

随着数据量增多，压力变大，引入分库分表操作：

• 分库：增多数据库，每个库存储一部分数据。
• 分表：一张表数据太大，按规则拆分，由多个库存储。

如何分？根据业务需求即可，永远记住：业务决定技术！

相关软件包括 Greenplum、TiDB、PostgresqlXC、HAWQ 等，商用如 GBase、LibrA 等。

微服务

将所有数据安排在具体整个服务器会导致维护困难。因此，按规则将应用拆分成多个小的服务器集群，每部分人只需维护对应集群，简化操作。

随着人员增加和业务扩展，将业务分给不同团队维护，每个团队独立实现微服务，互相隔离直接数据访问。利用 Gateway、消息总线等技术实现调用关联，甚至将用户管理、安全管理等业务提成为公共服务。

引入微服务有利有弊：

• 弊端：分散后需引入大量硬件资源，通信开销大（网络通信比硬盘读取慢），离散度增高导致维护成本增加。
• 优势：解决了人力管理问题，便于功能复用，支持不同服务独立部署。

总结

本文梳理了分布式系统的核心概念与演进路径：

• 单机架构：应用程序 + 数据库服务器。
• 数据库和应用分离：分别放到不同主机上部署。
• 负载均衡：通过负载均衡器，把请求均匀分发给集群中的应用服务器。
• 读写分离与主从结构：一个主节点负责写，N 个从节点负责读，主节点同步数据给从节点。
• 缓存与冷热数据分离：进一步提升处理能力，遵循二八原则。
• 分库分表：拓展数据库空间，缓解压力。
• 引入微服务：将应用拆分为功能单一、简单的服务器集群。