技术控

    今日:58| 主题:49211
收藏本版 (1)
最新软件应用技术尽在掌握

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

[复制链接]
曾那么需要你 发表于 2016-10-16 16:29:59
96 1

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
【今日话题】
怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复
璐姐总结:
服务可靠性的核心是:容灾,不过挺实用的,这个是个大话题,如果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太庞大了,怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复
  
怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复-1 (解决方案,数据恢复,服务器,稳定性,可靠性)

原来可以这样 - 黄隆
这个是个大话题,服务可靠性的核心是:容灾,不过挺实用的,这个是个大话题,如果down机,就自动切换到备份节点。比如服务来说,如果只有单节点,那么就部署多节点。并且适当的负载均衡策略,或者是自动切换策略。
一般简单解决方案就是:节点级别的,依赖于备份节点;IDC级别的依赖于备份IDC。恩,这里面都可能出现故障。  - 黑夜路人
机房断网等因素也会有。。。 - 卡特 - 360
节点再细分还有:交换机,机柜电源,服务器电源,服务器磁盘,网络出口(针对多线的机房) ... - 碧轩
推荐一本新出的书 Google 运维解密,不错,讲了很多谷歌内部的细节 - 所长别开枪
“Tomcat 使用apr优化” (文章链接请看下方的链接分享) - 黄隆
大型网站系统与Java中间件实践  这本书讲的不少这个些问题  - 是非
这个是简单宏观的容灾了。细致到服务与服务之间的交互和稳定性;服务本身的健壮性;举例说,如果A、B两个服务,A服务依赖于B服务,如果B服务挂了,A服务需要考虑能够正常工作。另外可靠性,是服务本身。比如连接超时,比如数据缓存 等等策略,另外是服务本身,比如服务本身是多进程的,如果管控某个进程出问题了不会影响整个服务稳定性;另外是如何这个服务挂了,有没有监控自启机制,等等,都是服务可靠性的一部分。我这些都偏开发,没太偏运维。运维维度很重要的在可靠性维度就是,就是包括 监控、报警、自动切换、负载均衡 等等。运维细致的监控几个层次:物理层(链路、设备)、系统层(系统稳定性、安全、内存、CPU、磁盘)、服务层(服务可用性监控,依赖服务监控、端口、进程)、应用层(代码、配置、日志),也可以按照维度来监控:接入维度、应用维度、数据存储维度 等等  - 黑夜路人
如果常驻运行的,可以用supervisord守护。。。 - 卡特 - 360
可以考虑open-falcon开源监控系统 - 秋天
从软件到硬件到系统到架构,其实都有一个共同的地方: cache - [email protected]
数据库 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并发更新缓存也没有问题 - 廖强
怎么个死法。。缓存失效的时候去下游更新数据的时候第一进程加个一分钟或者两分钟有效的缓存锁,更新完数据删除。其他进程查询这个锁里面有值就先不更新。如果第一个进程更新失败了导致锁没有删除,等锁自动失效其他进程再更新。 - 荣亮
都是热,但是不同的两种热,如果是热更新,另一个是热查询 - 老王
正常的缓存策略不存在更新一说,要么是add,要么删除,如果用到了更新,并发下基本缓存的数据可能会出现脏数据  - 廖强
对于php,缓存穿透有个很重要的原因是,null和not exitsts的区别,很多人都用empty判断返回的结果,但是,有可能缓存的数据就是“”,或0,导致被穿透 - tiyee
那又是写代码的人逻辑控制问题了吧。这算bug了吧。 - 荣亮
这些都写入就行了,空也记录上,应该算是经验 - 斯图尔特
弱类型的一些函数,不区分0,‘’,null - tiyee
这个很多都是习惯问题吧,写之前想想返回的值里面有没有0,'',null这种情况再决定怎么写就好了 - 骑马爬树
新手确实容易踩坑。 - 荣亮
好友一个就是缓存的原子性问题,对于获取数据列表,可以直接缓存所有的数据,也可以分两个缓存,一个缓存id列表,然后循环列表分别去获取id对应的数据,第二种方法本身是为了降低更新率,但是如果第一次缓存的时候,所有id对应的详情的时间社一样,容易同时失效  - tiyee
【其他问答】
EXPLAIN SELECT * FROM gb  WHERE active>1 AND catalog IN (2015122508572062,2015122608325096,2015122709514920,2015122809095989,2015122909255771) ORDER BY id DESC LIMIT 20,20;
我这样的语句  type只有index, 还有什么办法优化吗?数据量只有几十万  - vk
   直接执行要多久? - xingxing
   1.* s - vk
   不怕空间占用,就联合索引呗,catalog + id,还有active如果少的话,直接列出所有应该比较好点  - 胜邪
   active 有几种数据状态? - xingxing
   active 只有 1、2、3   - vk  
   那直接 active=1 or active=2呗,还有就是时间咋不用int格式存呢  - 胜邪
   catalog 也是一个 id 字段,以前旧程序,喜欢用日期再加随机数   - vk   
   给catalog加index,收益大啊,然后catalog和id联合索引呗,应该有效果的,你先试试 - 胜邪
   先尝试下把 active 的条件改下 看看执行时间是否有下降  - xingxing
   对啊,通过索引,能把数据范围缩小很多,比如你通过active的索引,最多才降低1/3的数据,当然收益小了  - 胜邪
   直接 active=1 or active=2   这个效果不错啊 - vk   
   所以像active这种 枚举字段,加索引的收益不大,这是一个对比,比如你有100万数据,1,2,3各有33万,那么你通过active的索引,只能定位到数据从33万里查找,如果从id这个主键的索引里找,一下就就找到了,因为是唯一的,当然,我说的只是一个通俗的解释 - 胜邪
   @vk 有效果就好 ,有机会可以优化下表结构,对长久来说会好很多   - xingxing
   我直接用这三个做索引,反而没效果 - vk
   一次查询只能用一个索引 - 胜邪
   我指定用了我新加的索引。 - vk
   你加多了没用,反而浪费空间,并且导致数据变更的时候,速度变慢,你用的是什么索引嘛  - 胜邪
   active catalog id 的联合索引  - vk
   针对这个表的 sql 平时可以统计下,然后再决定怎么优化,没必要这么设定联合索引  - xingxing
   active in(2,3),如果非要用> 1, 这个条件就要放在最后,利用前面的条件筛选出一个小结果集, 在小结果集上>1,性能会提高很多  - 我不叫大脸猫
   搞错了,active=3 OR active=2  没效果,因为刚刚是写成  active=1 OR active=2   - vk
   猫总,你的消息过时了,条件的位置问题不会影响查询,mysql自己会优化的,不是你写前面就先查  - 胜邪
   用OR的话, 性能也不好,会影响的, 孩纸,不要太相信MySQL自己的查询优化器  - 我不叫大脸猫
   反正我很多年前就做过试验了,不影响  - 胜邪  
   刚刚试了,好像没明显区别哇? - vk
   active catalog id 的联合索引?不用加active啊,效果不大,你用catalog+id试验下额 - 胜邪
   我现在是,catalog+id,  active  单独一个索引,一样是1.5s 以上  - vk
   EXPLAIN结果丢出来看下呢  - 胜邪
   gb就是联合索引?  - 胜邪
   这里用了主键的索引了,其实这不是重点啊,重点是才46行,这么慢,你是在pc上么?  - 胜邪
   gb就是 catalog+id,服务器,其他都挺快的   - vk
   服务器扫描48行的东西,用1.5s  - vk
   改成 active=1 的就 很快了,一样的explain
   SELECT * FROM gb  WHERE  catalog IN (2015122508572062,2015122608325096,2015122709514920,2015122809095989,2015122909255771) AND (active=1 OR active=2) ORDER BY id DESC LIMIT 20,20;
   (20 row(s) returned)
   Execution Time : 00:00:00:327
   Transfer Time  : 00:00:00:000
   Total Time     : 00:00:00:327   - vk
   整个表索引是怎样的? - weizhao
   active in(1,2)啊, 为啥要用or,用or肿么走索引 - 我不叫大脸猫
   你们没关注这么奇怪的事么,还有,你表数据是好多啊?  - 胜邪
   42条   - 我不叫大脸猫
   45w条总数 - vk
   就算没有索引,完全不是一个正常的时间 - 胜邪
   建表语句给下,然后再看看你的sql语句,以及explain结果。。。。  是不是查出的是大量字段,慢在io拿数据了。。。。 - weizhao
   @vk desc gb  看看,可能类型转换了,先看表定义 - 种树人
   不家active条件试试 - 胜邪
   走主键了 - 方圆
   不过,之前的人把这个表加了N个索引,几乎加满了字段,我还没仔细核对,所以没有删多余的索引,不加active条件,很快。FORCE INDEX (gb) ,只能强制使用联合索引, 这样就没事了, 刚刚我没仔细看,他之前是用主键。- vk
   我早就提醒过你啊  - 胜邪
   你不是说:其实这不是重点啊,重点是才46行 - vk
   对啊,因为我觉得奇怪,对了,不用active explain也发出来看看,有什么差别呢?能快点?你强制用联合索引就快了? - 胜邪
   EXPLAIN SELECT * FROM gb FORCE INDEX(gb)  WHERE  catalog IN (2015122508572062,2015122608325096,2015122709514920,2015122809095989,2015122909255771) AND active IN('2','3') ORDER BY id DESC LIMIT 20,20;
   严格来说我加了强制索引后,mysql反而不走索引了。
- vk
   库里是INT型的吗? 如果库里是 VARCHAR的,加上单引号 - 荒野猎人
   extra里有filesort不靠谱啊,对啊,先上表定义啊,desc 或者show create table下 - 种树人
   where条件的位置在范围查询下是有影响的   先给表定义  再给执行SQL和explain结果 .....  - weizhao

怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复-2 (解决方案,数据恢复,服务器,稳定性,可靠性)


   。。。。 果然是没用引号的问题。。
   MySQL类型转换是一大坑啊,规范要解决的 - 种树人
   没加引号,坑。。
   网上能找到新浪,去哪儿,赶集的MySQL规范,稍微调整下,然后在团队强制推行下,写个小工具自动扫下,就能避免一堆类似的问题
   没加引号的等等坑,关键他还强行把没加引号的 catalog 写入别的表。。。
问个tomcat问题,当low memory耗尽,不管high memory剩余多少,oom-killer都开始杀死进程,以保持系统的正常运转。这个怎么解决?
/var/log/messages 日志中,有如下信息:
Out of Memory: Killed process [PID] [process name].  - Mutitty
   oom可以调参数的,不过这个是有内存泄漏吧 - linbo
   解决内存泄露问题不是解决被杀问题 被杀是应该的  - 王春光
   是。有问题杀掉是对的,但是好像这个事情,内存剩余很多也会有出现 - Mutitty
   并不是你有内存就不能oom - viktor
   那个是系统决定的,linux可以配置禁用oom killer - 方圆
   内存不足只是一方面,你看下malloc的申请内存的机制,low memory限制,和low memory碎片过多都会触发oom - viktor
   malloc申请的只是虚拟内存地址,物理地址要用到的时候才会去申请的 - Song
   超过128走mmap了 - 金灶沐
   @Mutitty 偷偷修改一下oom算出来的分数,数值越小越不容易被干掉,oom的源码看过一部分,fork出来的子进程也会继承父进程的分数,很棘手 - viktor
   关掉oom呀~或者用64bit系统呀~  - 学在囧途
   系统是64位的。 - Mutitty
   把17写进oom_obj就杀不掉了 - viktor
群里有人做过dubbo的更深入的开发么 ? 或者你们的RPC,有没有这样的功能,根据用户的某些信息进行路由
不同的用户分布在不同的数据库中,想在应用层,也就是RPC的时候,进行路由 - smargo
   我们业务在调用rpc前做了个proxy自己封装了一下 - 闪亮的日子
   很少在 rpc 做分库的事情吧,被调用的那个服务应该自己做好路由,对调用方屏蔽这个细节 - yangmls
   @闪亮的日子,你的方案就是在调用方做? - smargo
   @yangmls,这确实是个矛盾的地方,如果是在调用方做,可以少一层,如果是在服务方做,那服务方就得多一层路由层 - smargo
   所以想请教一下大家,比较成熟的方案是什么样的 - smargo
   在哪方做proxy都可以,看业务了,在调用方做可以减少一次rpc,被调用方要判断下是不是自己的请求,不是自己处理的则转给对应的机器去处理 - 闪亮的日子
   转发这个比较NB。。。 - smargo
   在调用方不容易改啊,所以一般都是服务方做,而且一般服务方是无状态,很容易做负载均衡,你的分库策略变了,难道要所有的服务都重启一遍吗? - yangmls
   这个确实是个问题,我们的分库策略很简单,有一个库记录了的对应关系 - smargo
   rpc 一般只会实现比较通用的调度策略,比如 round bin 还有根据注册中心的 weight 值,你这种调 rpc 还得查一下数据库的建议不要和 rpc 做在一起 - yangmls
大家有人关注过 tidb 么? - [email protected]
   有,我正在读tidb的源码 - 廖强
   这个一致性和故障恢复的场景,其实是 tidb 这种类型的 newsql 数据库最擅长解决的问题  - [email protected]
   嗯,tidb的解决方案和我之前写的类似,区别在于我是在mysql源码基础上做的,然后在外面包了一个协调者,之前做的也比较有限,现在看有人让sql的解释引擎做成分布式的,这个当时没有涉及太深。当时基本还是延用mysql的sql解释器 - 廖强
   传统的 mysql 或者 mysql 中间件因为架构上的问题,在这方面都没有彻底完善的方案,这方面是需要新的架构和算法来保证的,所以必须从根本上进行创新,要么修改 mysql 源码,要么就重造一个,基本上没有其他的方法,semi sync 本身在某些场景下也会退化成异步,本质上还是会有丢数据的风险的,所以从理论上来说并不能保证数据的一致性的 - [email protected]
   很早之前mysql考虑这个事情,所以他支持了XA协议,但是内部里面的实现只支持了单机跨事务引擎的强一致性,把binlog作为2阶段提交的协调者。这个很坑,对,存在退化成异步的可能,要做的话,目前能想到的基本跟oceanbase的思路一致了 - 廖强
   分布式事务暂时也没有什么好的办法,基本主流的做法绕不开 2pc, 剩下就看工程实现了,比如可以考虑 batch write, batch read, txn scheduler 的工程实现了,感觉都是有性能瓶颈了,所以有分布式的需求,那基本上只能试用高吞吐的场景,不适用于低延迟。 - [email protected]
   一直关注tidb,想未来这个db稳定了,可以用到业务场景中去,目前还算看好。上次你们的创始人发微博嘲讽了一下mysql,引来了何登成的“反击”,哈哈。嗯,差不多就那些工程方法了,主流的做法都差不多,主要看细节了 - 廖强
   性能测试本来很多时候都是 bench marketing,主要 dongxu 就是那种随性的人,你们有空见下就知道了,也不是嘲讽 - [email protected]
   哈哈,还想着看看有没有机会成为tidb的commitor呢 - 廖强
   感谢大家对 TiDB 的关注啊 任何数据库都不是银弹,主要看它特点是什么,能带来什么价值,帮大家解决什么问题,才是最重要的,现在 TiDB 文档其实不是太完善,而且有些文档都比较过期了,包括部署试用搞起来都没那么顺滑,所以给大家深入了解这个项目带来了很多困扰,抱歉了 ,大家继续聊技术吧,技术本身才是最核心的,至于是什么数据库,只要能解决现有问题的就是好的数据库 - [email protected]
   内个TiDB会不会跟ssdb一样,搞个半成品给人用,后面无人维护啊,我们有业务用了ssdb,发现几次数据丢失 - tiyee
   不会啊,如果用 tidb 的话,我们全力 support @tiyee  - [email protected]
【今日分享】
如何评价Facebook推出的JavaScript模块管理器yarn? [ https://www.zhihu.com/question/51502849/answer/126177331?from=timeline&isappinstalled=0 ]
http如何像tcp一样实时的收消息? [ http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959605&idx=1&sn=21f25087bef3c3a966ef03b824365621&mpshare=1&scene=1&srcid=1012ULQzlv3dXCv8A1k56j5M#wechat_redirect ]
创业者的噩梦 - 为什么没人能帮忙。 [ http://mp.weixin.qq.com/s?__biz=MzI0MjA1Mjg2Ng==&mid=2649866978&idx=1&sn=1ae1c525f11ca2a38b92f7dd799caa03&chksm=f107588fc670d199a2d39414334d585eeebfdcf5740927209253c74016a110d3d539a9ad4b86&mpshare=1&scene=1&srcid=1012eD1iRqCntpPuyvIRR0ev#wechat_redirect ]
论获取缓存值的正确姿势 [ http://mp.weixin.qq.com/s?__biz=MzAxMzc4Mzk1Mw==&mid=2649836690&idx=8&sn=87fa4b06f5466ff65d5dbcd81b4173b8&chksm=8398aa6cb4ef237a587c027d98e959e1e4e12c745d824ed75cc2e508f70d165ddf00c0e8de77&mpshare=1&scene=1&srcid=1013GYm3IS4hIXkCOTrKduiJ#wechat_redirect ]
Tomcat 使用apr优化 [ http://blog.itpub.net/article.php?url=http://blog.itpub.net/29510932/viewspace-1102187/ ]
PHP7.0.0格式化字符串漏洞与EIP劫持分析 [ http://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651062125&idx=4&sn=8436e082eec9e6ac5e0be1f867b1d517&chksm=bd186de68a6fe4f046cebb26ad3a228e25240b0b8cfaec84d6bc6699d25801c6a621ac1fed0d&mpshare=1&scene=1&srcid=1013mp7ZrnSd2lvJm8laLCyp#wechat_redirect ]
【其他】
如对上述讨论有异议或更好的意见,请提出或在群里继续讨论
进群方式:公众号回复“进群”
友荐云推荐




上一篇:设计模式-Command
下一篇:【Java深入学习系列】三. 那些年我们用过的日志框架
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

莪依旧凄凉 发表于 2016-11-18 14:57:41
为何要放弃治疗?
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表