【今日话题】

怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复

璐姐总结:

服务可靠性的核心是:容灾,不过挺实用的,这个是个大话题,如果down机,就自动切换到备份节点。比如服务来说,如果只有单节点,那么就部署多节点。并且适当的负载均衡策略,或者是自动切换策略。

一般简单解决方案就是:节点级别的,依赖于备份节点;IDC级别的依赖于备份IDC。恩,这里面都可能出现故障。IDC故障,就是如果整个业务服务都在一个机房,整个机房如果down了,相当于整天个业务都完全无法服务了。节点故障,比如A服务是个Web或API应用,默认情况只有1台服务器,如果这台服务器压力太大,或者是服务器设备坏了,整个服务就down了。大灾难一般两种:节点故障、IDC故障。这个是简单宏观的容灾了。另外可靠性,是服务本身。

细致到服务与服务之间的交互和稳定性;服务本身的健壮性;举例说,如果A、B两个服务,A服务依赖于B服务,如果B服务挂了,A服务需要考虑能够正常工作。比如连接超时,比如数据缓存 等等策略,另外是服务本身,比如服务本身是多进程的,如果管控某个进程出问题了不会影响整个服务稳定性;另外是如何这个服务挂了,有没有监控自启机制,等等,都是服务可靠性的一部分。

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

数据一致性的问题也比较复杂。cap 理论来说:在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼 。实时性要求比较高的业务,一般是要求实时一致;实时性要求不高的,一般是保证最终一致。以数据库和分布式存储系统距离,数据库主从算是实时性比较强的,比如mysql的主从机制,特别在新版本里面,各种什么多线程同步,什么组同步机制,都极大层面保证了数据一致的实时性,但是,主要有网络、磁盘这些问题的差异在,就不可能完全在不同节点中数据同一时间完全一致。

分布式系统来说,很多都是最终一致的思路。举例说,大部分分布式系统,一般每份数据都会有多份镜像备份数据,一些做法是只要你数据写入了3个镜像数据里的主镜像完成,就认为你数据写入完成,然后后续再慢慢的通过主镜像慢慢同步到从镜像。这种是最终一致。也有一些系统,必须是比如3个镜像数据,必须每个镜像数据都完全写入完成了,都返回数据write done,才会告诉你数据写入成功。

我们大部分LNMP架构的业务来说,普遍存在的数据存储三类:数据库持久化数据、缓存数据、静态文件数据- 黑夜路人

部署同城容灾,同城双机房,建议看 google 那本 sre 的书 - yangmls

自动运维和监控,还是得看规模和发展阶段吧,规模大了,就是刚性需求了,初期就几十台机器的话,部署各自动化运维至少十几台机器吧,都赶上业务的了,也就没人搞了,或者可以用现在的第三方的云监控方案,一般都得装个agent,又觉得不安全 - 李鑫

Web服务器的容灾挺成熟的了,主要是数据中心还涉及到数据同步到问题,谁赐教一下啊 ?还有redis,这些呢?- 胜邪

同步就用otter喽,redis你要同步那就自己基于redis协议做类似otter,MySQL复制一般都是binlog, 好像也没有其他办法了一样的工具喽 ,数据一致性要有redo日志 - 我不叫大脸猫

我们的运维包括 dba 都很强势,会制定各种规范,不合理的设计说不让你上就不让你上,我就在运维部门。。。这种组合在阿里就叫技术保障部 - yangmls

运维开发+DBA+安全工程师 这种系统部的组合,一般来说会比较强势 ,业务开发/服务开发/架构和资源开发 这种组合也挺强势的,业务/服务 级别的 强一致性可以借助 ZK 最终一致性可以借助 Consul,数据库方面,如果不是事物集中的,可以用 Percona XtraDB 集群,跟 小黑 说的那个 存三份数据 的概念类似 - xingxing

事务集中,这个怎么理解?能否举个简单的例子? - 胜邪

应该是说分布式事务吧 - 我不叫大脸猫

四年前的一个测试数据时 230+事务/秒 会出现性能瓶颈(四台机器的集群) - xingxing

从实操层面来说,mysql举例,目前来看,依赖于自带的主从同步来保证一致和高度实时性。如果涉及到跨机房数据备份,就需要考虑如果用消息队列这种带来的实时性问题。redis的问题基本跟mysql类似吧。最后一个就是关于down机后数据的恢复 ,mysql的恢复方式众多,包括innodb从事务日志里面恢复数据;从binlog恢复数据等等。redis从rdb文件恢复数据;从aof文件里恢复数据等等。另外一个就是需要做好数据镜像工作了,包括主从同步、热数据备份、离线数据备份等等,不能等出事了再就追悔莫及了。 - 黑夜路人

事务这东西,我理解的不深。接触太少了,事务,分布式事务,都各种怎么理解呢? - 胜邪

分布式事务就是有AB两个事务, A在a节点上执行, B在b节点上执行, 普通事务就是都在a节点上执行 - 我不叫大脸猫

rdb我们都关了,bgsave的时候会阻塞几秒的时间, 并且如果单机内存使用量大, 瞬间 就会爆机,刚开始用redis的时候不了解这个特性, 被坑惨了,比较好奇银行的容灾是怎么做的,银行应该更精细, 容忍丢小客户一天的数据, 但是没办法容忍丢几个大客户几秒的数据 - 我不叫大脸猫

BGSAVE 执行期间仍然可以继续处理客户端的请求,为啥会阻塞几秒?? - Ado

我遇到的问题是,硬盘满了,rdb写不进去了,然后redis就拒绝服务了 - 胜邪

读请求不会阻塞啊,写请求肯定会阻塞啊 - 我不叫大脸猫

save 直接调用 rdbSave ,阻塞 Redis 主进程, bgsave fork 出一个子进程,子进程负责调用 rdbSave - Ado

我遇到的是内存爆掉了 - 我不叫大脸猫

数据层面的容灾 很大程度上就是“容忍”数据丢失的程度,我们以前做过一段时间的“临时方案”,在服务层“打回去”,给数据层处理争取些时间,让老板直观感觉到需要投入成本,在数据层面做容灾投入的时候,很多事情就会好做些,当然也就是为了防患于未然,毕竟业务层的决策者,不一定了解或理解,服务层做的事情,更自然的在数据层方面的意识更薄弱些,保证业务是王道,能争取到多大资源投入,然后再拆分这些资源到不同的维度上去完善架构和策略,比刚开始要个比较多的资源容易很多 - xingxing

"http如何像tcp一样实时的收消息?" (文章链接请看下方的链接分享) - 黑夜路人

会不会服务器一直被hold住,然后连接多了后服务器资源不够用,一台服务器的连接应该是有上线的。而且貌似并不是很多 - Dd

有人Zeromq用么? - 小火箭

用过,虽然号称宇宙最快,但会丢消息,扩展的兼容性也是不行,丢消息这个蛋碎,zmq php扩展有问题,跑久了php-fpm会挂 - 种树人

只用过rabbitmq,各位选用消息队列的时候怎么选呀 - 叶茂升

众多大厂在用的,或者超级简单的,刚毕业的都能改的动的 - 种树人

用稳定的 - yongsean

对稳定的评估的能力比大厂用高,大厂都在前面填坑的,心里踏实 - 种树人

不过也要确定大厂内部是否在用,有些大厂技术在外面推广,结果里面自己人都知道有坑,不用,这个就比较坑爹 - 三千

多看啊,拿到开源项目先看user case,没有3,5个以上大厂用的先star就好,有的就简单用起来,通过大厂用来选型其实就是把评估、填坑、最佳实践等的工作都交给大厂的大师。

也是"把复杂留给大师,简单留给自己"的一个途径 - 种树人

那大厂都是用什么消息队列的? - smarteng

大厂各个项目不一样吧 - 胜邪

自建的 - 谢敏

我们小厂机器联网用activemq,稀里糊涂的用 - 黄旭

这年头应该 kafka 最多,大厂像阿里造过很多轮子,notify rocketmq等等 - yangmls

如果不宕机的话一切都好说,宕机且机器不可恢复的话,mysql的异步复制和半异步复制都有可能会丢失数据。mysql同步复制性能差,异步/半异步复制可能会丢数据。微信做了一个proxy,在收到进入请求后先同步到多数机器上,再返回,这样会解决一部分丢数据的问题。

- 闪亮的日子

“论获取缓存值的正确姿势” (文章链接请看下方的链接分享) - 黑夜路人

所以还是得评估对于丢数据的容忍度,非常重要的数据得开全同步复制

==============

昨天研究了一下 apr,发现内置的东西也很全面。 - 黑夜路人

路姐,apr是什么? - 陈亦

Apache Portable Runtime Library [ http://apr.apache.org/ ],从Apache项目里诞生的各种c库 - 黑夜路人

tomcat+apr 实现高性能 - 是非

路姐,是相于c的函数库么? - 陈亦

是的 - 黑夜路人

apache太庞大了,怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复


怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复

原来可以这样 - 黄隆

这个是个大话题,服务可靠性的核心是:容灾,不过挺实用的,这个是个大话题,如果down机,就自动切换到备份节点。比如服务来说,如果只有单节点,那么就部署多节点。并且适当的负载均衡策略,或者是自动切换策略。

一般简单解决方案就是:节点级别的,依赖于备份节点;IDC级别的依赖于备份IDC。恩,这里面都可能出现故障。 - 黑夜路人

机房断网等因素也会有。。。 - 卡特 - 360

节点再细分还有:交换机,机柜电源,服务器电源,服务器磁盘,网络出口(针对多线的机房) ... - 碧轩

推荐一本新出的书 Google 运维解密,不错,讲了很多谷歌内部的细节 - 所长别开枪

“Tomcat 使用apr优化” (文章链接请看下方的链接分享) - 黄隆

大型网站系统与Java中间件实践 这本书讲的不少这个些问题 - 是非

这个是简单宏观的容灾了。细致到服务与服务之间的交互和稳定性;服务本身的健壮性;举例说,如果A、B两个服务,A服务依赖于B服务,如果B服务挂了,A服务需要考虑能够正常工作。另外可靠性,是服务本身。比如连接超时,比如数据缓存 等等策略,另外是服务本身,比如服务本身是多进程的,如果管控某个进程出问题了不会影响整个服务稳定性;另外是如何这个服务挂了,有没有监控自启机制,等等,都是服务可靠性的一部分。我这些都偏开发,没太偏运维。运维维度很重要的在可靠性维度就是,就是包括 监控、报警、自动切换、负载均衡 等等。运维细致的监控几个层次:物理层(链路、设备)、系统层(系统稳定性、安全、内存、CPU、磁盘)、服务层(服务可用性监控,依赖服务监控、端口、进程)、应用层(代码、配置、日志),也可以按照维度来监控:接入维度、应用维度、数据存储维度 等等 - 黑夜路人

如果常驻运行的,可以用supervisord守护。。。 - 卡特 - 360

可以考虑open-falcon开源监控系统 - 秋天

从软件到硬件到系统到架构,其实都有一个共同的地方: cache - 王晶@半桶水

数据库 IDC容灾 切换 各个公司都是怎么做的? - 大大政

IDC容灾,,这个太高级了,,主从库真不敢切,备份机房,只读的到是可以,如果有交易的话,没法搞 - akin520

idb数据库备份,一般都是搞个读库,我经历过的都是dba手动切的 - 大大政

数据一致性的问题也比较复杂。cap 理论来说:在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼 。实时性要求比较高的业务,一般是要求实时一致;实时性要求不高的,一般是保证最终一致。以数据库和分布式存储系统距离,数据库主从算是实时性比较强的,比如mysql的主从机制,特别在新版本里面,各种什么多线程同步,什么组同步机制,都极大层面保证了数据一致的实时性,但是,主要有网络、磁盘这些问题的差异在,就不可能完全在不同节点中数据同一时间完全一致。分布式系统来说,很多都是最终一致的思路。举例说,大部分分布式系统,一般每份数据都会有多份镜像备份数据,一些做法是只要你数据写入了3个镜像数据里的主镜像完成,就认为你数据写入完成,然后后续再慢慢的通过主镜像慢慢同步到从镜像。这种是最终一致。也有一些系统,必须是比如3个镜像数据,必须每个镜像数据都完全写入完成了,都返回数据write ,我们大部分LNMP架构的业务来说,普遍存在的数据存储三类:数据库持久化数据、缓存数据、静态文件数据done,才会告诉你数据写入成功。 - 黑夜路人

服务可靠性 加监控+预警 数据一致性最好是双写 保证数据不丢 及时纠正 宕机数据修复:没遇到过这情况 不敢说 我觉得log先加上 - wangjing

这里说数据一致性,好像都没有考虑拜占庭问题 ,(军队与军队之间分隔很远,传讯息的信差可能在途中路上阵亡,或因军队距离,不能在得到消息后即时回复,发送方也无法确认消息确实丢失的情形,导致不可能达到一致性。)一般我们用的一致性协议,例如paxos,zab raft,其实都没有解决拜占庭问题 - 郑杰文

paxos是不考虑拜占庭问题的,默认通信可靠 - cloes

嗯,paxos认为消息是不会被篡改,然后还有一个就是坏人的容忍度,有些节点可能被入侵 - 郑杰文

估计很容易联想到微服务 - 黄隆

是呀,哈。微服务也没啥,就是把独立功能块的服务单独处理,减低依赖,或者单个大服务出问题后的雪崩。 -黑夜路人

就是因为有了前面的问题,然后演化成微服务嘛,单个服务影响整个系统 - 黄隆

从实操层面来说,mysql举例,目前来看,依赖于自带的主从同步来保证一致和高度实时性。如果涉及到跨机房数据备份,就需要考虑如果用消息队列这种带来的实时性问题。redis的问题基本跟mysql类似吧。 -黑夜路人

用不用消息队列,跨机房都有时延问题,跨机房还要分情况,跨机房主要是看有没有跨运营商 - 廖强

最后一个就是关于down机后数据的恢复 ,mysql的恢复方式众多,包括innodb从事务日志里面恢复数据;从binlog恢复数据等等。redis从rdb文件恢复数据;从aof文件里恢复数据等等。另外一个就是需要做好数据镜像工作了,包括主从同步、热数据备份、离线数据备份等等,不能等出事了再就追悔莫及了。 - 黑夜路人

@黑夜路人 终于把你说的看完了 考虑挺全面 数据恢复这块最好在之前做好压测,做好机器储备 预防宕机,高流量可以考虑异步 队列,譬如抢购 - wangjing

如果都是电信的,其实跨机房的时延问题不太大。如果跨了运营商,就需要利用到并行复制的机制,通过大的吞吐量来解决时延 - 廖强

恩,强哥方案靠谱 ,我基本的宏观架构思路都说完了,实操细节就好多了,需要具体问题具体聊。因为话题比较宏观,我就从架构师维度简单说了下。 - 黑夜路人

备份和恢复工作有一个大家容易忽略的就是延迟备份,在dba不小心删了数据的时候,可以更快的恢复数据 - 廖强

mysql 数据恢复就好多细节,哈。innodb 的 recovery 就比较复杂。 - 黑夜路人

各位按照路哥讲的,能把细节和深入度做好,就可以做架构师了 - 廖强

mysql 新版本有 innodb_force_recovery 选项能够做一些,不过推荐关闭,不然会影响每次启动的效率。印象里5.6以后才有 - 黑夜路人

其实mysql5.5也好多问题,5.6我觉得才算是mysql的一个比较完整的版本 - 廖强

mysql 真是越来越牛逼了,5.1我就觉得很优秀,因为我从4.0开始用的嘛,然后越来越牛了 - 黑夜路人

从原来的no sql到现在的no!sql,哈哈 - 廖强

5.6的包括 innodb_force_recovery,包括 group commit 啥的,都很赞。 - 黑夜路人

嗯,还是semi sync - 廖强

mysql 就差一个分布式解决方案了,对 semi sync,如果有了分布式解决方案,就不错了,不过我不敢用 semi sync,哈,怕出问题。去年年初研究了一下 mycat,觉得算是一个简单不错的分布式解决方案了,哈。但是还考虑再线上使用 - 黑夜路人

业务只要不需要支持分布式事务,方案就简单不少,如果不支持分布式事务,有的使用不当,容易造成潜在问题 - 廖强

“论获取缓存值的正确姿势” (文章链接请看下方的链接分享) - 黑夜路人

不对吧,如果访问量非常大,为何要用这种被动缓存呢?不是应该主动缓存吗 - tiyee

不一样啊,热键问题缓存也没失效,也不存在更新 - 老王

加锁 。。。 这不是要死的节奏 - 李冬

核心都是热键的问题,如果对不同的key并发更新缓存也没有问题 - 廖强

怎么个死法。。缓存失效的时候去下游更新数据的时候第一进程加个一分钟或者两分钟有效的缓存锁,更新完数据删除。其他进程查询这个锁里面有值就先不更新。如果第一个进程更新失败了导致锁没有删除,等锁自动失效其他进程再更新。 - 荣亮

本文数据库(mysql)相关术语:navicat for mysql mysql workbench mysql数据库 mysql 存储过程 mysql安装图解 mysql教程 mysql 管理工具

分页:12
转载请注明
本文标题:怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复
本站链接:http://www.codesec.net/view/484392.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(mysql) | 评论(0) | 阅读(60)