江苏龙网

  1. 首页 > 资讯 > 科技 > >

数据库|开源分布式关系型数据库TiDB入坑指南( 三 )


TiDB 是无状态的 ， 推荐至少部署两个实例 ， 前端通过负载均衡组件对外提供服务 。 当单个实例失效时 ， 会影响正在这个实例上进行的 Session ， 从应用的角度看 ， 会出现单次请求失败的情况 ， 重新连接后即可继续获得服务 。 单个实例失效后 ， 可以重启这个实例或者部署一个新的实例 。
2）PD
PD 是一个集群 ， 通过 Raft 协议保持数据的一致性 ， 单个实例失效时 ， 如果这个实例不是 Raft 的 leader ， 那么服务完全不受影响；如果这个实例是 Raft 的 leader ， 会重新选出新的 Raft leader ， 自动恢复服务 。 PD 在选举的过程中无法对外提供服务 ， 这个时间大约是3秒钟 。 推荐至少部署三个 PD 实例 ， 单个实例失效后 ， 重启这个实例或者添加新的实例 。
3）TiKV
TiKV 是一个集群 ， 通过 Raft 协议（raft一致性哈算法以及Raft 为什么是更易理解的分布式一致性算法 ）保持数据的一致性（副本数量可配置 ， 默认保存三副本） ， 并通过 PD 做负载均衡调度 。 单个节点失效时 ， 会影响这个节点上存储的所有 Region 。 对于 Region 中的 Leader 结点 ， 会中断服务 ， 等待重新选举；对于 Region 中的 Follower 节点 ， 不会影响服务 。 当某个 TiKV 节点失效 ， 并且在一段时间内（默认 30 分钟）无法恢复 ， PD 会将其上的数据迁移到其他的 TiKV 节点上 。
五、TiDB适用及不适用场景1、TiDB 的典型的应用场景是
(1) 原业务的 MySQL 的业务遇到单机容量或者性能瓶颈时 ， 可以考虑使用 TiDB 无缝替换 MySQL 。
TiDB 可以提供如下特性：
1）吞吐量、存储和计算能力的水平扩展
2）水平伸缩时不停服务
3）强一致性分布式 ACID 事务
(2) 大数据量下 ， MySQL 复杂查询很慢 。
(3) 大数据量下 ， 数据增长很快 ， 接近单机处理的极限 ， 不想分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的 Sharding 方案 。
(4) 大数据量下 ， 有高并发实时写入、实时查询、实时统计分析的需求 。
(5) 有分布式事务、多数据中心的数据 100% 强一致性、auto-failover 的高可用的需求 。
2、TiDB 不适用场景
(1) 单机 MySQL 能满足的场景也用不到 TiDB 。
(2) 数据条数少于 5000w 的场景下通常用不到 TiDB ， TiDB 是为大规模的数据场景设计的 。
(3) 应用数据量小（所有数据千万级别行以下） ， 且没有高可用、强一致性或者多数据中心复制等要求 ， 不适合使用 TiDB 。
觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容 ， 感兴趣的朋友可以关注下~

数据库|开源分布式关系型数据库TiDB入坑指南
本文插图


推荐阅读


上一篇：高通|京东“牵手”高通，川普很满意，高通不愿离开中国“梦想”或成真

下一篇：|2020年5月农业类创业公司传播影响力TOP20：科技农业类公司占比超五成