首页  思维导图  详情

设计架构容量评估标准

2022-06-29 10:23:47   0  举报





AI智能生成

设计架构容量评估标准

作者其他创作

大纲/内容

通用标准

按照峰值的5倍冗余

一般简单的业务按照当前规模乘以2~4即可。现在基数低就乘以4，高就乘以2

分库分表后容量一般可储存30年的数据

第三方查询吞吐量为5000/s

单条数据库记录占用大约1kb的空间

容量评估步骤

1. 确定评估方案

App/网站

前端加载为秒级别

每日一共又多少用户来访

独立Ip访问

每日单独用户的所有页面访问量。

最大性能方案

如果网站刚刚上线还没有办法确定数据量级，可以参考业界类似知名网站当前的量级来设计最大性能方案

案例

最小资源方案

2. 参考参考值，计算各种机器数量

参考值

IDC

同一机房网络来回 0.5 ms

同一机房RPC调用为几毫秒

500毫秒算超时

异地机房来回 30 ~ 100 ms

MySQL

单接口读

1000/s

单接口写

700/s

单表容量

5000 万条

读写混合部署情况下

单接口读

单接口写

单条记录大于 500ms就可以认为超时

MySQL在 4c 256gb的性价比最高

DB2

单机读

20000/s

单机写

20000/s

单表容量

1亿条

Kafka

单机读

30000/s

单机写

5000/s

RocketMQ

单机读

30000/s

单机写

2700/s

NoSQL

Redis

单接口读

40000/s

性能极高 – Redis 能读的速度是 110000 次/s

单接口写

40000/s

,写的速度是 81000 次/s 。

一个端口 32gb

采用多少个集群，具体的数据量储存需要多少

容量估算

一个redisObject

一个 RedisObject 包含了 8 字节的元数据和一个 8 字节指针，需要16字节内存

每个key-value都是两个redisObject即需要32字节，剩下的才是对应的sds，hash等string的大小

sds

buf：字节数组，保存实际数据。为了表示字节数组的结束，Redis 会自动在数组最后加一个“\0”，这就会额外占用 1 个字节的开销。
len：占 4 个字节，表示 buf 的已用长度。
alloc：也占个 4 字节，表示 buf 的实际分配长度，一般大于 len。

string数据格式的内存消耗

int 类型消耗16字节

embstr固定消耗 16字节 + sds

sds

所以一个string消耗的内存最小是

redisObject+int编码

16 字节 + 16字节

32字节

redisObject+embstr编码

16字节 + 16字节 + 8字节 + 1字节（sds的结束符）

41字节

redisObject+raw编码

16字节 + 16字节 + 8字节 + 45字节（sds的结束符）

95字节

list数据结构的内存消耗

listNode结构占用的总字节数为24，list结构占用的总字节数为48。

有序集合

zskiplist结构占用的总字节数为32。

字典

dictht结构占用的总节数为32。

jemalloc内存分配规则
　　jemalloc是一种通用的内存管理方法，着重于减少内存碎片和支持可伸缩的并发性，做redis容量评估前必须对jemalloc的内存分配规则有一定了解。

jemalloc基于申请内存的大小把内存分配分为三个等级：small，large，huge：

Small Object的size以8字节，16字节，32字节等分隔开，小于页大小；
Large Object的size以分页为单位，等差间隔排列，小于chunk的大小；
Huge Object的大小是chunk大小的整数倍。
对于64位系统，一般chunk大小为4M，页大小为4K，内存分配的具体规则如下：

集群部署方式

三主三从

Elasticsearch

需要确定的内容

一个集群需要多少个节点，一个索引需要多少个分片

单条文档的尺寸/文档的总数据量/索引的总数据量（Time base 数据保留的时间）/副本分片数

文档是如何写入的（Bluk的尺寸）

文档的负责程度，如何读取（聚合查询还是普通查询）

业务性能需求评估

数据写入吞吐量

查询吞吐量

单条最大返回值

数据的格式和数据的Mapping

实际查询和聚合长什么样子

ES主要分两类应用

日志类搜索

基于时间序列的数据

使用ES存放日志/性能指标，数据每天不断写入，增长速度较快

结合Warm Node做数据的老化处理

业务数据类搜索

固定大小的数据集

搜索的数据集增长相对比较缓慢

硬件配置

业务数据类搜索

选择合理的硬件，业务数据节点尽可能是ssd

搜索等性能要求高的场景，建议使用ssd

建议按照1：10 比例配置内存和硬盘

日志/性能，查询并发需求地的场景

考虑使用机械硬盘

按照1：50 的比例配置内存和硬盘

单节点硬盘建议控制在2TB内，最大不超过5TB

JVM配置留一半的内存给系统，因为segment同步到文件系统的缓存。 jvm最大不建议超过32gb

集群部署方式

提高高可用和可靠性，可以考虑master 和 data节点分离，3master，3data，如果有复杂的查询和聚合，建议设置专门的coordinating节点

注意脑裂

es容量规划建议

每个shard 不超过20gb

在单机存储1TB数据场景下，SATA盘和SSD盘的全文检索性能对比（测试环境：Elasticsearch5.5.3，10亿条人口户籍登记信息，单机16核CPU、64GB内存，12块6TB SATA盘，2块1.5 TB SSD盘）：

https://www.elastic.co/guide/en/elasticsearch/guide/current/capacity-planning.html

节点

master node

1. 创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。

2. 维护并更新 cluster state

使用低配置cpu，ram和磁盘

data node

保持分片数据

使用高配置cpu，ram和磁盘

ingest node

默认每个节点打开

使用高配置cpu，中等ram，低配置磁盘

coordinating node

machine learning

特殊节点类型

Hot & Warm NOde

冷热节点

ML node

机器学习的节点

Tribe Node

部落节点

分片的配置与优化

7.0 primary 分片默认改成了1

当分片数 > 节点数时，一旦集群中有新的节点加入，分片就可以自动进行分配，建议 primary shards > nodes

日志类应用，单分片不要超过50gb

业务类应用，单分片不要超过20gb

副本也会占用资源，建议使用1就好，可以增加replica，增加读的吞吐量

避免分布不均匀

如果某个节点磁盘满了，新的节点加入，可能分片会集中到新的节点去，可以设置下面的值避免这个问题

index.routing.allcation.total_shards_per_node

cluster.routing.allcation.total_shards_per_node

应用服务器的峰值

5000/s

使用 Dubbo 的会员服务项目
每天接收 4 亿次远程调用
使用 12 台网站标配机器提供服务（8 核 CPU，8G 内存）
平均负载在 1 以下（对于 8 核 CPU 负载很低）
平均响应时间 2.3 到 2.5 毫秒，网络开销约占 1.5 到 1.6 毫秒（和数据包大小有关）
使用 Dubbo 的产品授权服务项目
每天接收 3 亿次远程调用
使用 8 台网站标配机器提供服务（8 核CPU，8G 内存）
平均负载在 1 以下（对于 8 核 CPU 负载很低）
平均响应时间 1.4 到 2.8 毫秒，网络开销约占 1.0 到 1.1 毫秒（和数据包大小有关）

测试报告

3. 什么时候该扩容？

节点一般一般看load值

1个cpu的load 保持在0.7以下是好的

N核cpu < N * 0.7

CPU

寄存器、L2、L3、内存、分支预测失败、互斥量加锁和解锁等耗时为纳秒级别

内存

内存随机读写可达 30万次/s

顺序读取可达500 万次/s

每秒可以读取GB级别的数据

读取1MB数据为250ns