关于服务器:深度好文服务器扩容思路及问题分析

为什么要扩容

说人话就是, 无论如何优化性能, 能达到的最大值是肯定的, 对于一个用户量大的利用, 能够对服务器进行各种优化, 诸如限流、资源隔离, 然而下限还是在那里, 这时候就应该扭转咱们的硬件, 例如应用更强的 CPU、更大的内存, 在前文中举了一个学生食堂打饭的例子, 如果学生多了, 能够通过令牌桶算法优先给高三学生令牌打饭, 然而如果高三的学生还是很多呢? 那就只有减少窗口或者食堂的数量, 也就是硬件上的扩容。

扩容策略

扩容策略能够分为两种, 一种是对单机整体扩容, 也就是机器外部蕴含 CPU、内存、存储设备等, 另一种是扩容对应的组件, 例如扩内存、扩磁盘、扩 CPU。

整机硬件

整机扩容的益处是, 有很多业余的服务器硬件供应商, 例如 IBM、浪潮、DELL、HP 等, 业余的硬件供应商, 他们组装以及搭配方面可能教训更加丰盛, 另外有些公司会对组件进行一些优化, 从而服务器更加稳固, 能够类比为买电脑, 有的人可能抉择买淘宝卖家曾经组装好的台式, 有的人可能本人买各种硬件本人回家组装, 对于个别人而言, 抉择前者是较为靠谱的抉择, 因为你即便懂硬件的一些参数, 也难保本人搭配的机器是否能施展各个部件最大性能。

组件

对于一些技术能力强悍的公司, 更多的是本人买各种组件组装, 这样老本更低, 因为节俭了组装等费用, 并且能够依据业务个性化定制, 例如有的公司是计算密集型的, 那么次要是更换更强的 CPU, 有的 IO 密集型, 那么扩容的应该是内存等, 有的公司须要存储大量的数据, 那么可能扩容的是硬盘等存储设备。

组件蕴含:

• cpu

  • Intel、Amd , 参考频率、线程数等

• 网卡

  • 百兆 -> 千兆 -> 万兆

• 内存

  • ECC 校验

• 磁盘

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

AKF 拆分准则

在 Redis 集群拆分准则之 AKF 中, 具体介绍了 AKF 拆分准则的详情, 这儿简略回顾一下:

对于一个利用, 如果单机不足以撑持服务申请, 那么能够建设诸如主主、主从等模式的集群:

这个叫 AKF 准则 X 轴扩大, 目标是将申请分流在多台机器上, 然而多台机器两头要解决数据同步性的问题, 越多的机器数据不同步的可能性越大, 这也就意味着没法有限整体复制扩容。所以能够整顿收集服务器内热点的业务申请, 将业务分离出来, 只对热点业务进行扩容, 这就是 AKF 准则的 Y 轴拆分:

对业务拆分之后, 某个业务还可能太热点, 也就是 Y 轴拆分后程度复制还是不足以撑持数据申请, 那么能够将业务的数据进行拆分, 具体来说就是, 某个业务的数据, 能够放在多个中央, 例如在湖北、北京、上海部署机房, 各地的人们须要申请数据时, 由离得近的服务器提供服务。

拆分扩容后存在的问题

随着业务的增长，零碎变得越来越宏大, 依据零碎性能拆分成独立而又互通的我的项目, 比方交易系统、财务零碎、生产流程零碎、物流零碎、网站零碎等等, 然而分布式构造会存在很多问题。对于这些问题每一个都值得深入探讨, 这儿简略的提一下, 前面再开篇幅。

数据共享问题

所有的服务之间数据如何共享同步, 这是一个须要思考的问题, 微服务架构中, 数据不可能只有一份, 没法防止机器损坏等起因造成的数据失落, 多份数据之间如何同步? 目前可供参考的解决思路是建设数据中心、搭建数据库集群。

接口调用问题

不同的服务器之间进行调用遵循近程调用协定 RPC

JAVA RMI：Java 近程办法调用，即 Java RMI（Java Remote Method Invocation）是 Java 编程语言里，一种用于实现近程过程调用的应用程序编程接口。它使客户机上运行的程序能够调用近程服务器上的对象。

dubbo: 提供了面向接口代理的高性能 RPC 调用

长久化数据雪崩问题

• 数据库分库分表, 参考:MySQL 调优之分区表。
• 资源隔离, 参考: 亿级流量架构之资源隔离思路与办法。
• 缓存设定数据长久化策略:Redis 长久化之 RDB 和 AOF。

高并发问题

缓存: 诸如缓存击穿、穿透、雪崩等, 参考 Redis 击穿、穿透、雪崩产生起因以及解决思路。

数据闭环: 为了便于了解, 举个例子, 对于淘宝而言, 有网页版、IOS 版、安卓版、还有什么一淘等等, 尽管客户端不一样, 然而展现的商品信息是雷同的, 也就是一件商品, 无论是哪个端用的数据是一样的, 须要一套计划来解决并发下依据雷同数据在不同端进行不同展现的问题, 这就叫数据闭环。

数据一致性问题

这是一个难点, 粗心就是多个服务器之间数据如何保障一致性, 同样的商品在不同客户端服务端端价格应该是一样的, 通常应用分布式锁。

数据库扩容: 集群

先简略说一下分布式与集群的区别, 这两个词儿常常一起呈现, 然而意义却有所不同, 分布式会缩短单个工作的执行工夫来晋升工作效率，而集群强调的是进步单位工夫内执行操作数的减少来提高效率。更简略的来说，分布式是将步骤分到每台电脑上，不思考依赖关系，集群计划是指几个工作同时在解决。

繁多数据库存储难以满足业务需要时, 采取集群的形式, 将数据存储在不同的服务器, 这能够是主主或者主从, 主从中主负责写, 从负责读, 将与数据库无关的压力进行合成到多台机器上。

分布式 ID

在简单分布式系统中，往往须要对大量的数据和音讯进行惟一标识。很容易想到的是利用自增, 然而自增有很多问题，例如 ID 有太强的法则, 可能会被歹意查问收集, 面对数据日渐增长，对数据分库分表后须要有一个惟一 ID 来标识一条数据或音讯，这样数据库的自增 ID 显然不能满足需要；特地一点的如商品、订单、用户也都须要有惟一 ID 做标识。此时一个可能生成全局惟一 ID 的零碎是十分必要的。概括下来，那业务系统对 ID 号的要求有哪些呢？

分布式 ID 要求

面对分布式 ID, 须要满足上面的要求:

• 全局惟一 性：不能呈现反复的 ID 号，既然是惟一标识，这是最根本的要求。
• 趋势递增：在 MySQL InnoDB 引擎中应用的是汇集索引，因为少数 RDBMS 应用 B -tree 的数据结构来存储索引数据，在主键的抉择下面咱们应该尽量应用有序的主键保障写入性能。
• 枯燥递增：保障下一个 ID 肯定大于上一个 ID，例如事务版本号、IM 增量音讯、排序等非凡需要。
• 信息安 全：如果 ID 是间断的，歹意用户的扒取工作就非常容易做了，间接依照程序下载指定 URL 即可；如果是订单号就更危险了，竞对能够间接晓得咱们一天的单量。所以在一些利用场景下，会须要 ID 无规则、不规则。

上述 123 对应三类不同的场景，然而 3 和 4 的需要是互斥的，也就是无奈应用同一个计划满足。除了对 ID 号码本身的要求，业务还对 ID 号生成零碎的可用性要求极高，设想一下，如果 ID 生成零碎瘫痪，整个与数据无关的动作都无奈执行，会带来一场劫难。由此总结下一个 ID 生成零碎起码应该做到如下几点：

• 均匀提早和 TP999 提早都要尽可能低；
• 可用性 5 个 9(这是美团的要求, 有些企业例如阿里要求 6 个 9)；
• 高 QPS。

分布式 ID 生成策略

目前业界罕用的 ID 生成策略有很多, 例如 UUID、雪花生成算法、Redis、Zookeeper 等, 这儿只简略讲讲 UUID 以及 Snowflake，前面要开篇详谈。

UUID 生成算法

UUID(Universally Unique Identifier)的规范型式蕴含 32 个 16 进制数字，以连字号分为五段，模式为 8 -4-4-4-12 的 36 个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有 5 种形式生成 UUID，详情见 IETF 公布的 UUID 标准 A Universally Unique IDentifier (UUID) URN Namespace。

• 长处：

  • 性能十分高：本地生成，没有网络耗费。

• 毛病：

  • 不易于存储：UUID 太长，16 字节 128 位，通常以 36 长度的字符串示意，很多场景不实用。
  • 信息不平安：基于 MAC 地址生成 UUID 的算法可能会造成 MAC 地址泄露，这个破绽曾被用于寻找梅丽莎病毒的制作者地位。
  • ID 作为主键时在特定的环境会存在一些问题，比方做 DB 主键的场景下，UUID 就十分不实用：

① MySQL 官网有明确的倡议主键要尽量越短越好[4]，36 个字符长度的 UUID 不符合要求。

All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.

​ ② 对 MySQL 索引不利：如果作为数据库主键，在 InnoDB 引擎下，UUID 的无序性可能会引起数据地位频繁变 动，重大影响性能。

雪花生成算法

这种计划大抵来说是一种以划分命名空间（UUID 也算，因为比拟常见，所以独自剖析）来生成 ID 的一种算法，这种计划把 64-bit 别离划分成多段，离开来标示机器、工夫等，比方在 snowflake 中的 64-bit 别离示意如下图（图片来自网络）所示：

41-bit 的工夫能够示意 （1L<<41）/(1000L360024*365)=69 年的工夫，10-bit 机器能够别离示意 1024 台机器。如果咱们对 IDC 划分有需要，还能够将 10-bit 分 5 -bit 给 IDC，分 5 -bit 给工作机器。这样就能够示意 32 个 IDC，每个 IDC 下能够有 32 台机器，能够依据本身需要定义。12 个自增序列号能够示意 212 个 ID，实践上 snowflake 计划的 QPS 约为 409.6w/s，这种调配形式能够保障在任何一个 IDC 的任何一台机器在任意毫秒内生成的 ID 都是不同的。

这种形式的优缺点是：

• 长处：

  • 毫秒数在高位，自增序列在低位，整个 ID 都是趋势递增的。
  • 不依赖数据库等第三方零碎，以服务的形式部署，稳定性更高，生成 ID 的性能也是十分高的。
  • 能够依据本身业务个性调配 bit 位，非常灵活。

• 毛病：

  • 强依赖机器时钟，如果机器上时钟回拨，会导致发号反复或者服务会处于不可用状态。

弹性扩容

说人话, 就是让集群依据打算在某一段时间主动对资源进行扩容，并在设置的打算还原工夫时开释资源。这样能解决规律性的资源峰谷需要，达到充沛正当利用资源的目标。

然而弹性扩容有一些问题:

第一，虚拟机弹性能力较弱。应用虚拟机部署业务，在弹性扩容时，须要通过申请虚拟机、创立和部署虚拟机、配置业务环境、启动业务实例这几个步骤。后面的几个步骤属于公有云平台，前面的步骤属于业务工程师。一次扩容须要多部门配合实现，扩容工夫以小时计，过程难以实现自动化。如果能够实现自动化“一键疾速扩容”，将极大地提高业务弹性效率，开释更多的人力，同时也打消了人工操作导致事变的隐患。

第二，IT 老本高。因为虚拟机弹性能力较弱，业务部门为了应答流量顶峰和突发流量，广泛采纳预留大量机器和服务实例的做法。即先部署好大量的虚拟机或物理机，依照业务顶峰时所需资源做预留，个别是非顶峰时段资源需要的两倍。资源预留的方法带来十分高的 IT 老本，在非顶峰时段，这些机器资源处于闲暇状态，也是微小的节约。

作者：等不到的口琴
链接：cnblogs.com/Courage129/p/14425669.html