扩容
扩容的原因
单体应用 -> 平均
硬件与云服务扩容
整机硬件
整机: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成本,在非高峰时段,这些机器资源处于空闲状态,也是巨大的浪费。