大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说TcaplusDB君的小知识之TcaplusDB的高可用性和数据安全性介绍,希望您对编程的造诣更进一步.
随着信息化的发展，数据库已经是企业正常运营必不可少的工具，企业的所有数据都存储在数据库上，因此可以说数据库的可靠与否关系着企业的生死存亡。
因此，数据的保护和备份是数据库业务的重中之重，系统的可用性以及数据的可靠性对数据库来说都是至关重要的。
数据库的可用性是指数据库在规定的条件下使用时维持其正常功能的能力。其量化参数为可用度，表示数据库产品在规定的条件下使用时，在某时刻维持其正常业务功能的概率。高可用性的数据库提供自动快速地转移到备份的全自动故障转移，这样，用户和应用程序可以继续工作，而不会中断。
而数据一致性指数据库的关联数据之间的逻辑关系是否正确和完整，数据一致性可以确保用户所取的数据结果的一致。
而对于TcaplusDB而言，设计数据库系统的可用性和数据一致性，最重要的是满足用户的需求，从用户的需要出发，才能够设计出最好的数据库。
下面TcaplusDB君将介绍TcaplusDB的高可用性和数据安全性以及灾备机制。
高可用
TcaplusDB组件默认采用高可用部署：
- 管理节点tcapcenter采用Master/Slave模式部署，当Master故障时自动切换到Slave。
- 管理节点tcapdir会部署多个进程。
- 接入层tcaproxy采用冗余方式，单个接入层节点故障不会导致用户请求处理异常。
- 存储层tcapsvr，采用Master/Slave模式，主从切换无损。 存储层tcapsvr Master/Slave和接入层tcaproxy部署优先采用同城跨机房部署，也支持跨机架、跨交换机、跨楼层等部署方式。
数据一致性保障
对于TcaplusDB来说，有完善的数据一致性保障措施，具体如下所示:
- 正常读写场景：主备通过binlog来保证数据一致性，主备会按严格一致的时间顺序执行binlog；主备时间差约10ms； 业务读写请求均在主节点执行。
- 主备切换： 系统主动切换会先等待数据完全同步后，再进行切换。故障切换若因master进程已不存在， 可能丢失10ms左右数据，此时因老请求还连在原master上，TcaplusDB主备同步目前采用的是异步写的机制，当数据写主过程中故障，有可能数据还未来得及同步备机连接就断了，此时数据就可能会丢失，目前所使用的内外客户对这种损失程度还处于可接受范围，不会对业务造成太大影响。目前针对这个情况，项目组也在计划设计强同步机制，确保数据不会丢，不过带来的就是会牺牲一定的吞吐量。
- 周期性主备数据一致性全量对比: 根据用户需要，在低峰期对全量数据做一致性对比。对比过程因前端读写产品的不一致会根据记录修改时间自动判断并重复校验, 以发现系统潜在的不一致风险。 通常做法是抽查一些核心表的部分数据分片来进行全量比对，以保障比对效率。
- 冷备数据一致性保障: 备节点在做全量冷备时，冷备开始时间点全量数据文件处于完全静止状态，此时全量数据采用字节copy来进行备份, 完全无一致性问题。 且在冷备期间，前端读写完全不受影响，新请求会写入小的修改集，请求会合并全量数据和小修改集。
- 数据落地安全保障: 业务数据在存储节点落地时有CRC校验， 若因数据被篡改， CRC校验会失败， 不会因此返回给用户错误的数据。
灾难恢复
TcaplusDB API维护了一致性Hash环，当增加或者减少接入层节点时，TcaplusDB API会自动调整接入层tcaproxy的信息。
- 接入层异常：TcaplusDB每秒会向接入层tcaproxy发送心跳，若接入层节点在10s内没有返回响应，则TcaplusDB API会主动标注该节点不可用，使用其他节点。
- 存储层异常：tcapsvr Slave发生异常时会被一个新的Slave节点替换。如果tcapsvr master发生异常， Slave会切换成Master，切换过程中的用户请求失败，建议开发者增加重试逻辑代码。Master/Slave支持亚健康切换，读写错误率达到阈值时（默认80%）即进行主从切换，如下图：
灾难恢复示意图
接入层tcaproxy和存储层tcapsvr均有过载保护功能，超过预留读写的请求会触发错误码返回。
最后
我们已经了解了 TcaplusDB 的高可用性和数据安全性以及灾备机制，后续我们将揭开更多TcaplusDB设计的特殊奥秘。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/6388.html
