亿级流量系统多级缓存架构7

扩容

扩容的原因

单体应用 -> 平均

硬件与云服务扩容

整机硬件

整机：IBM、浪潮、DELL、HP等

cpu

Intel、Amd 单路，双路，四路

网卡

千兆 -> 万兆

内存

ECC校验

磁盘

SCSI HDD（机械）、HHD（混合）、SATA SSD、PCI-e SSD、 MVMe SSD

水平扩容

复制

统一入口 负载均衡

系统拆分

随着业务的增长，系统变得越来越庞大

根据系统功能拆分成独立而又互通的项目

比如交易系统、财务系统、生产流程系统、物流系统、网站系统等等

拆分完成会发生以下问题

• 系统间共享数据

  • 中央数据中心，数据库集群
  • 独立资源，消息中间件异步消费数据

• 接口调用

  • rpc rmi dubbo
  • http restful

• 持久化数据雪崩

  • 数据库分库分表
  • 资源隔离
  • 对访问量大的

• 静态资源分布在各个系统中

  • 防刷
  • cdn技术统一分发管理

• 高并发问题

  • 缓存
  • 数据闭环

• 数据一致性问题

  • 分布式锁

多库join

增加冗余字段设计

向多库发n次查询

复制表到本地数据库

使用搜素引擎

连接表

以MySQL为例，链接表与常见的 MyISAM, InnoDB 等等，都是一种表的结构类型（称之为 存储引擎）。使用 show engines; 命令即可看到数据库所支持的存储引擎，默认 FEDERATED 引擎 是关闭的，我们需要去mysql配置文件开启它。

开启的方法很简单，在windows下只需要在mysql的配置文件 my.ini 最末尾加上一句 federated ，然后重启mysql即可。重启后输入 show engines;命令即可看到 FEDERATED 的 Support 变为 YES，表示federated引擎已经开启。

链接的表，那么会有以下几个限制：

• 本地的表结构必须与远程的完全一样
• 远程数据库目前仅限MySQL
• 不支持事务
• 不支持表结构修改

一个例子

        CREATE TABLE TABLE2 (
        id     INT(20) NOT NULL AUTO_INCREMENT,
        name   VARCHAR(32) NOT NULL DEFAULT '',
        other  INT(20) NOT NULL DEFAULT '0',
        PRIMARY KEY  (id),
        INDEX name (name),
        INDEX other_key (other)
        )
        ENGINE=FEDERATED
        DEFAULT CHARSET=latin1
        CONNECTION='mysql://192.168.1.2:3307/DB2/TABLE2';

分布式ID

并发场景下的id生成策略

分布式ID需求

• 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。

• 递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。

• 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。

• 极高的可用性

• 高并发

单机id 自增和随机哪个效率高？

分布式ID方案

全局唯一数据库

集群中唯一的一台数据库服务器

特点

• 实现简单
• 性能一般，难扩展
• 维护
• 整形id自增，分页，排序等需求很方便
• 由于每个数据库产品对id生成策略实现不同，数据库中的数据迁移跨数据库平台需要处理
• 单点故障问题

数据库集群生成方案

避免重复，设置成起始数字不一样，步长一样

UUID

可以用数据库生成，也可以用代码生成

• 简单
• 不可读
  • 变种，替换或增加字段用来存储生成时间
• 生成性能好，没有网络开销
• 全球唯一，数据合并一般不会出问题
  • mac地址，原子钟
  • 保证服务器时间不回退
• 无法排序，没有递增关系
• 字符串存储空间大，查询效率较低
• 数据传输量大

zookeeper

自身高可用，原子性

• 有序，使用临时序号节点
• 使用节点的数据版本号
• 高并发下性能不好

MongoDB

使用ObjectId，原生分布式数据库

Redis

单线程的redis可以提供原子特性及高性能

实现分布式id可以用Redis的原子操作 INCR和INCRBY来实现起始数字不一样，步长一样

• 高性能
• 数字id，排序，分页方便
• 局部有序，全局无法保证有序

snowflake

snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID

这种方案大致来说是一种以划分命名空间（UUID也算，由于比较常见，所以单独分析）来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图

• 性能好
• 单机上是递增的，强依赖机器时钟，分布式系统中无法保证每台机器时钟都一样，所以不是全局递增
• 机器上时钟回拨

分布式事务

弹性扩容

虚拟机

第一，虚拟机弹性能力较弱。使用虚拟机部署业务，在弹性扩容时，需要经过申请虚拟机、创建和部署虚拟机、配置业务环境、启动业务实例这几个步骤。前面的几个步骤属于私有云平台，后面的步骤属于业务工程师。一次扩容需要多部门配合完成，扩容时间以小时计，过程难以实现自动化。如果可以实现自动化“一键快速扩容”，将极大地提高业务弹性效率，释放更多的人力，同时也消除了人工操作导致事故的隐患。

第二，IT成本高。由于虚拟机弹性能力较弱，业务部门为了应对流量高峰和突发流量，普遍采用预留大量机器和服务实例的做法。即先部署好大量的虚拟机或物理机，按照业务高峰时所需资源做预留，一般是非高峰时段资源需求的两倍。资源预留的办法带来非常高的IT成本，在非高峰时段，这些机器资源处于空闲状态，也是巨大的浪费。