很多用户在调研完 TiDB 之后，就会进入测试环节，这里详细描述一下硬件选型的相关考虑点。
测试环境
首先来谈谈测试环境。如果是纯兼容性验证，推荐官网上的 docker-compose 部署即可，后面会单独列一份 docker 部署上可能会遇到的问题 list，不过一般来说，docker 部署都是比较简单易用的。
如果希望有一些直观上的印象，比如大概了解一下 tidb-ansible，各组件的启停，配置，日志等。可以申请一台配置稍高点的虚拟机，16C32G，将几个组件都部署在同一台服务器上，这样也是可以 run 的，只是无法做高可用、性能等相关测试。
如果希望做一些功能测试验证，例如在线添加缩容节点，破坏性测试等，那么必须要满足以下基本条件
1、tidb-server 至少两台服务器（虚机）
2、tikv-server 至少三台服务器（虚机），注意是三台独立的服务器，而不是三个 tikv 实例
3、pd-server 至少三台服务器（虚机，可以和 tidb-server 混合部署）
也就是至少五台服务器，当然如果要测试添加节点，得再准备一台服务器作为备用。如果想测试 tidb-server 的高可用，还得准备 haproxy 的服务器（测试的话也可以和 tidb-server 混合部署）。
有些用户会找过来，说你们的 pd 扩容方案按照官网的操作失败了，最后一查只有一台 pd-server，添加到两台。这种由于 pd-server 内部也组了一个 raft-group，它也得满足多数派协议，所以只有一个 pd-server 的话是没法 rolling_update 的，只能先 stop 集群再 start 才可以。还有一些用户只有两台服务器，上面部署了多个 tikv 实例，虽然看似满足了3个 tikv 节点的需求，但是要知道如果在一台服务器上部署多个 tikv 实例，pd 的调度是不会把数据在这台服务器上存储多份的，因为这样对于高可用来说毫无意义。所以上面的要求是最低要求，如果不满足，就不要做相关的功能性测试，因为结果一定是非预期的。
生产环境
有些人可能会说，还会有一种测试场景，那就是性能测试。对于 TiDB 来说，如果要测性能，那么两大基本条件 SSD 磁盘 + 万兆网络是必须要满足的，所以这个场景也一并归纳到生产环境来说吧。
首先看看TiDB 集群各组件的功能
1、tidb-server
主要负责接收 client 端的请求，解析并转化为 kv-api 发送给 kv，同时也会承担部分聚合计算的功能（如果计算无法下推，或者需要对下推的结果集再次进行计算的场景）。所以 tidb-server 的资源规划就很明显了，如果是典型的 TP 类场景，业务并发较高，但几乎都是点查点写，那么整个系统的瓶颈大概率先出现在 tidb-server，所以 tidb-server 的 cpu 高一点，数量多一点是一个更好的选择。如果是 AP 类场景，业务并发较低（100以下），那么 tidb-server 的 cpu 不太可能成为瓶颈，选择大一点的内存会更好。
2、tikv-server
主要负责数据的存储，同时在 tikv-server 上有两个进程分别是 corprocessor 和 schedule 来负责处理读写请求，可以认为 tikv 不仅仅是存储节点，它也会负责（大）部分计算的功能。如果是 TP 类场景，查询的瓶颈一般会先出现在 tidb 上，如果是写入量较高，那么更多的 tikv 实例是更好的选择，推荐是3的倍数。如果是 AP 类场景，需要更多 CPU，内存以及更多的 tikv 实例。
3、pd-server
主要负责两个功能，一是全局唯一的事务号的分配，二是整个集群的元数据信息。所以 pd-server 不需要太多的资源，8c32G 内存，200G 磁盘就可以，在集群规模较大元数据较多的情况下，推荐使用 SSD 磁盘。但是 pd-server 的稳定性对于整个集群来说至关重要，所以推荐单独的服务器部署 pd-server，而且要有三个节点。
4、monitor-server
主要负责监控数据的收集以及展示，如果节点数（tidb 实例 + tikv 实例 + pd 实例）数量超过10个，推荐16c32G 及以上配置，目前默认保留15天的监控数据，后面可能会调整为一个月或者更长，磁盘空间按照2G 每个实例每15天来计算即可。建议 monitor 服务器单独部署，不要跟其他组件混合部署，否则监控数据落盘的时候可能会引起资源竞争，极端的情况遇到过影响到 pd，从而集群短时间不可用的案例。
5、haproxy + keepalived （集群外组件）
主要负责 tidb-server 的负载均衡及高可用切换，建议单独部署，根据业务并发量来申请配置，至少不低于8core，而且 haproxy 的配置文件中需要开启多线程以及 timeout 时间调长。
综合来看，结论如下：
1、监控服务器需要单独部署，可以用虚机，推荐16c32G 及以上配置，可以用普通磁盘，空间按照每个（tidb/ tikv/ pd）实例4GB /月来估算。
2、pd 服务器对于性能要求不高，但是需要稳定，所以推荐单独部署8c16g200G SSD 磁盘即可，生产环境必须要部署3个 pd 节点。如果一定要混合部署，只能和 tidb 一起，并且要保证 tidb-server 的压力不大。否则一旦出现 tidb 把服务器的 cpu 吃光，或者把内存吃光出现 oom，可能会影响到 pd，甚至会引起整个集群短时间不可用的情况。
3、tikv 服务器必须独立部署，数据目录必须为 SSD，如果为 Nvme 磁盘更好，如果是公有云服务器选择本地 SSD 磁盘。tikv 服务器可以考虑多实例部署，按照每个 tikv 实例 16core，64G 内存，1.5T 的磁盘来配比即可。最佳实践是，例如服务器是2路12core 的 CPU 型号，打开超线程之后就是48core，那么配置内存最好是256G，同时配置3块独立的单块容量不超过2T 的 Nvme 磁盘。单台服务器的数据目录不能像 Hadoop 的存储节点一样配置几十 T，试想一下如果在线环境出现服务器下线的情况，十T 的数据 rebalance 到其它节点，对于集群性能和时延的影响是很大的，这一点跟 Hadoop 的离线系统不太一样。
4、tikv 服务器的磁盘最好用 Nvme 磁盘，最多2个 tikv 实例共享一块 Nvme 盘，如果是普通 SSD 磁盘，那么不管做不做 RAID，都不要出现多个 tikv 实例共享一块磁盘的情况。如果是普通 SSD，可以考虑多块盘做 RAID10的方式来增加随机读的 IOPS，但是写入的 IOPS 几乎跟单盘类似，没有明显的提升。生产环境不推荐用 RAID0的方式，因为损坏1块磁盘之后整个 RAID 组不可用，虽然 tikv 有多副本的机制能够将影响降到最低，但是 tikv 的下线上线，上 T 数据的迁移调度是会对性能和时延产生影响的。另外生产环境的数据库服务器也不推荐 RAID5，如果坏了一块磁盘，对于写入的影响非常大，而分布式系统存在木桶效应，如果某一个tikv 实例的写入非常慢，会影响到整个集群的性能。所以结论就是，要么不用 RAID，要么用 RAID10，其他方式都不推荐，当然首推 Nvme 磁盘，其次是 RAID10 的普通 SSD。
5、tidb 服务器的 cpu 不需要太高，48c足够，如果是 AP 业务，内存推荐128G 以上。磁盘几乎没有要求，普通的机械盘即可，如果需要开启binlog 功能，容量在1T 以内也基本够用了，如果规模比较大的集群需要导出数据或者做全量备份，推荐在指定的一个 tidb-server 上挂一个容量较大的外挂磁盘即可。生产环境至少2台 tidb-server，这样前端接 haproxy / F5 才能保证高可用，如果业务并发较高，或者希望做多个业务侧在计算层的资源隔离，也可以按需规划。
6、haproxy 需要独立部署，跟监控服务器一样，可以用虚机来做，一般会部署两台服务器，然后通过 keepalived 做高可用。因为后端的 tidb-server 是无状态的，所以不需要担心类似 MySQL 方案中的脑裂现象。
7、有一些小的细节方面，例如 tikv 实例（非服务器）数量，推荐为3的整数倍，这是为了调度侧考量，如果非核心业务场景，可以关闭 tikv 的 sync_log 参数，整体写入性能应该会有30%的提升。
配置上面需要注意的地方
除了上面所说的这些除外，下面列一些在日常支持中经常遇到客户配置错误的地方。
1、标签
如果存在 tikv 多实例部署，或者跨机房部署集群的情况，一定要注意 label 的配置。而 label 除了在 inventory.ini 文件中，tikv 指定好别名和 labels 之外，还需要配置下面的参数
TiKV1-1 ansible_host=172.16.10.4 deploy_dir=/data1/deploy tikv_port=20171 labels="host=tikv1"
## Group variables
[pd_servers:vars]
# location_labels = ["zone","rack","host"]
注意将上面的 location_labels 的注释去掉，按需配置。如果在集群首次部署的时候没有配置，那么通过 pd-ctl config set location_labels "zone, rack, host" 也可以设置成功，具体可以参考官网的 FAQ，搜索 label。
2、多实例部署时，需要将 CPU、内存、可用磁盘空间显示的配置好，具体参考官网部署集群的章节。默认的配置文件是按照单实例来分配的，如果多实例不指定的话就会出现 CPU 和内存争用的情况。
3、pd 调度 kv 节点的一个重要依据是，各 tikv 节点数据目录的使用率，如果手工在某一个 tikv 节点的 data 目录下放置了一个大文件，可能会引起内部的调度，将数据迁移走，最好避免这种情况的影响。
4、在做集群 tikv 节点下线的过程中，offline 只是告诉 pd ，该节点需要进入下线状态，把这个节点上的 leader 调度走的同时补全副本数，直到所有数据副本补全才会进入 tombstone 状态，这时才能将这个 tikv 进程停掉并清理数据。
自建机房推荐配置
云上的一些推荐型号
