Onelong

分享知识,与你一起进步......
RSS icon Home icon
  • 怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复

    post by onelong / 2016-10-14 5:30 Friday [工作]

    服务可靠性的核心是:容灾,大灾难一般两种:节点故障、IDC故障。

    IDC故障,就是如果整个业务服务都在一个机房,整个机房如果down了,相当于整天个业务都完全无法服务了。

    节点故障,比如A服务是个Web或API应用,默认情况只有1台服务器,如果这台服务器压力太大,或者是服务器设备坏了,整个服务就down了。

    一般简单解决方案就是:节点级别的,依赖于备份节点;IDC级别的依赖于备份IDC。如果down机,就自动切换到备份节点。比如服务来说,如果只有单节点,那么就部署多节点。并且适当的负载均衡策略,或者是自动切换策略。另外可靠性,是服务本身。细致到服务与服务之间的交互和稳定性;服务本身的健壮性;举例说,如果A、B两个服务,A服务依赖于B服务,如果B服务挂了,A服务需要考虑能够正常工作。比如连接超时,比如数据缓存 等等策略。另外是服务本身,比如服务本身是多进程的,如果管控某个进程出问题了不会影响整个服务稳定性;另外是如何这个服务挂了,有没有监控自启机制等等,都是服务可靠性的一部分。

    运维维度很重要的在可靠性维度就是,就是包括 监控、报警、自动切换、负载均衡 等等。运维细致的监控几个层次:物理层(链路、设备)、系统层(系统稳定性、安全、内存、CPU、磁盘)、服务层(服务可用性监控,依赖服务监控、端口、进程)、应用层(代码、配置、日志),也可以按照维度来监控:接入维度、应用维度、数据存储维度 等等

    数据一致性的问题也比较复杂。

    cap 理论来说:在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼 。

    实时性要求比较高的业务,一般是要求实时一致;实时性要求不高的,一般是保证最终一致。

    以数据库和分布式存储系统距离,数据库主从算是实时性比较强的,比如mysql的主从机制,特别在新版本里面,各种什么多线程同步,什么组同步机制,都极大层面保证了数据一致的实时性,但是,主要有网络、磁盘这些问题的差异在,就不可能完全在不同节点中数据同一时间完全一致。

    分布式系统来说,很多都是最终一致的思路。举例说,大部分分布式系统,一般每份数据都会有多份镜像备份数据,一些做法是只要你数据写入了3个镜像数据里的主镜像完成,就认为你数据写入完成,然后后续再慢慢的通过主镜像慢慢同步到从镜像。这种是最终一致。也有一些系统,必须是比如3个镜像数据,必须每个镜像数据都完全写入完成了,都返回数据write done,才会告诉你数据写入成功。我们大部分LNMP架构的业务来说,普遍存在的数据存储三类:数据库持久化数据、缓存数据、静态文件数据,微服务也没啥,就是把独立功能块的服务单独处理,减低依赖,或者单个大服务出问题后的雪崩。

    从实操层面来说,mysql举例,目前来看,依赖于自带的主从同步来保证一致和高度实时性。如果涉及到跨机房数据备份,就需要考虑如果用消息队列这种带来的实时性问题。redis的问题基本跟mysql类似吧。用不用消息队列,跨机房都有时延问题,跨机房还要分情况,跨机房主要是看有没有跨运营商,如果都是电信的,其实跨机房的时延问题不太大。如果跨了运营商,就需要利用到并行复制的机制,通过大的吞吐量来解决时延。

     

    最后一个就是关于down机后数据的恢复,mysql的恢复方式众多,包括innodb从事务日志里面恢复数据;从binlog恢复数据等等。redis从rdb文件恢复数据;从aof文件里恢复数据等等。另外一个就是需要做好数据镜像工作了,包括主从同步、热数据备份、离线数据备份等等,不能等出事了再就追悔莫及了。备份和恢复工作有一个大家容易忽略的就是延迟备份,在dba不小心删了数据的时候,可以更快的恢复数据,mysql 数据恢复就好多细节,innodb 的 recovery 就比较复杂。mysql 新版本有 innodb_force_recovery 选项能够做一些,不过推荐关闭,不然会影响每次启动的效率。印象里5.6以后才有,5.6的包括 innodb_force_recovery,包括 group commit、semi sync 啥的,都很赞。mysql 就差一个分布式解决方案了。业务只要不需要支持分布式事务,方案就简单不少,如果不支持分布式事务,有的使用不当,容易造成潜在问题。semi sync 本身在某些场景下也会退化成异步,本质上还是会有丢数据的风险的,所以从理论上来说并不能保证数据的一致性的,分布式事务暂时也没有什么好的办法,基本主流的做法绕不开 2pc, 剩下就看工程实现了,比如可以考虑 batch write, batch read, txn scheduler 的工程实现了,感觉都是有性能瓶颈了,所以有分布式的需求,那基本上只能试用高吞吐的场景,不适用于低延迟。

    引用地址:
     

    我要评论