1.【山东】2023年电热水壶产品质量省级监督抽查结果
2023年第1批产品质量省级监督抽查共抽查电热水壶产品28批次，其中，生产领域5批次，流通领域23批次。
本次抽查依据GB 4706.1-2005《家用和类似用途电器的安全 第1部分：通用要求》、GB 4706.19-2008《家用和类似用途电器的安全 液体加热器的特殊要求》等标准的要求，对电热水壶产品的对触及带电部件的防护、输入功率和电流、发热、工作温度下的泄漏电流和电气强度、耐潮湿、泄漏电流和电气强度、非正常工作（不包括第19.11.4条的试验）、稳定性及机械危险、机械强度、结构（不包括第22.46条试验和22.103条试验）、内部布线、电源连接和外部软线、外部导线用接线端子、接地措施、螺钉和连接、电气间隙、爬电距离和固体绝缘等项目进行了检验。
本次抽查发现临沂市君升不锈钢制品有限公司1家生产者生产的1批次产品和日照市东港区精采小家电中心销售的1批次产品不符合相关标准的要求，不合格项目为非正常工作（不包括第19.11.4条试验）、结构（不包括第22.46条试验和22.103条试验）、电源连接和外部软线、接地措施、电气间隙、爬电距离和固体绝缘。
对本次抽查发现的不合格产品生产者、销售者，山东省市场监督管理局已责成相关市场监督管理部门依据《中华人民共和国产品质量法》《产品质量监督抽查管理暂行办法》以及国家市场监督管理总局、山东省市场监督管理局关于监督抽查的有关规定，做好不合格结果处理工作。
2023年电热水壶产品质量省级监督抽查不合格情况汇总表序号产品名称抽查领域企业名称统一社会信用代码标称生产企业名称生产日期或批号规格型号商标抽查结果不合格项目承检单位备注1不锈钢电水壶生产领域临沂市君升不锈钢制品有限公司91371312MA3Q8JXU7N临沂市君升不锈钢制品有限公司2023.4.22/-26 220V 50Hz 1500WJUNSHENG君升不合格接地措施、非正常工作（不包括第19.11.4条试验）、电源连接和外部软线山东省计量科学研究院
2电热茶艺炉流通领域日照市东港区精采小家电中心92371102MABUA4NE0J广东海利集团有限公司2021.12/2022.1/-K9金灶不合格电气间隙、爬电距离和固体绝缘、结构（不包括第22.46条试验和22.103条试验）山东省计量科学研究院
2023年电热水壶产品质量省级监督抽查合格情况汇总表序号产品名称抽查领域企业名称统一社会信用代码标称生产企业名称生产日期或批号规格型号商标抽查结果承检单位备注1无绳电水壶生产领域青岛澳柯玛生活电器有限公司9137021158782725XJ青岛澳柯玛生活电器有限公司2022年12月/-ADK-1500G1AUCMA合格山东省计量科学研究院
2电水壶生产领域山东多星电器科技有限公司91370306MA3TJ2DR14山东多星电器科技有限公司2023.01.05/-DX-KB006多星科技合格山东省计量科学研究院
3自动保护不锈钢电水壶生产领域山东多星电器有限公司91370306706020329X山东多星电器有限公司2023.4.10/-CSCK-1500多星合格山东省计量科学研究院
4电热水壶（开水煲）生产领域山东胜宁电器有限公司91371422MA3CTRDD4P杭州九阳生活电器有限公司2023.3.15/-K17FD-W6350Joyoung九阳合格山东省计量科学研究院
5电热水壶流通领域滨州东润电器有限公司91371625MA3MXHR942广东美的生活电器制造有限公司-/2303130360MK-SH15Colour102Midea合格山东省计量科学研究院
6飞利浦电水壶流通领域滨州东润电器有限公司91371625MA3MXHR942飞利浦家电（中国）投资有限公司2022.11.10/-HD9350PHILIPS合格山东省计量科学研究院
7电热水壶流通领域聊城百大三联家电有限公司91371500MA3R1QFN7P小熊电器股份有限公司2022.9.6/2023.3.7/-YSH-C08T1小熊合格山东省计量科学研究院
8电热水壶流通领域聊城百大三联家电有限公司91371500MA3R1QFN7P小熊电器股份有限公司2022.12.14/-ZDH-Q15E1小熊合格山东省计量科学研究院
9电开水瓶流通领域齐河县汇轩商贸有限公司91371425MA3C4CLD8Y广东格兰仕微波生活电器制造有限公司2020-09/-P3Galanz合格山东省计量科学研究院
10电热开水瓶流通领域齐河县汇轩商贸有限公司91371425MA3C4CLD8Y佛山市海迅电器有限公司2023.3/-HX-8039AUX合格山东省计量科学研究院
11电热水壶流通领域齐河县美多电器销售有限公司91371425MA3QEJPW5X合肥长虹美菱生活电器有限公司2023.1/-MH-K28MELING 美菱合格山东省计量科学研究院
12电热水壶流通领域齐河县美多电器销售有限公司91371425MA3QEJPW5X合肥荣事达小家电有限公司2023.2/-RSD-8165荣事达Royalstar合格山东省计量科学研究院
13电热水壶流通领域日照市东港区精采小家电中心92371102MABUA4NE0J佛山市格来德小家电有限公司2023.3.11/2022.11.9/-WKF-318S格来德合格山东省计量科学研究院
14电热水壶流通领域日照银座商城有限公司购物广场91371102663540083K江苏省格来德净水科技有限公司2023.2.9/-D2818K格来德合格山东省计量科学研究院
15电热水壶流通领域日照银座商城有限公司购物广场91371102663540083K浙江爱仕达生活电器有限公司2022.12.12/-AW-S17G112A爱仕达合格山东省计量科学研究院
16电水壶流通领域山东三源家电有限公司913709007892732598浙江绍兴苏泊尔家居用品有限公司2022.11.11/-SW-17S36ASUPOR苏泊尔合格山东省计量科学研究院
17双层保温电水壶流通领域山东三源家电有限公司913709007892732598浙江绍兴苏泊尔生活电器有限公司2022.10.13/-SW-17S58ASUPOR苏泊尔合格山东省计量科学研究院
18电水壶流通领域山东省博兴县天元购物广场有限公司91371625321791288Y浙江绍兴苏泊尔生活电器有限公司220627/220929/-SW-15S02ASUPOR合格山东省计量科学研究院
19电热水壶（养生壶）流通领域山东省博兴县天元购物广场有限公司91371625321791288Y中山市荣鑫电器有限公司2022.5.15/-XF-R29新飞合格山东省计量科学研究院
20电热水壶（开水煲）流通领域泰安银座商城有限公司913709007262092842杭州九阳生活电器有限公司2022.6.7/-K17-F30Joyoung九阳合格山东省计量科学研究院
21电热水壶流通领域泰安银座商城有限公司913709007262092842广东美的生活电器制造有限公司2022.11.4/-MK-HJ1708Midea合格山东省计量科学研究院
22电热水壶（开水煲）流通领域泰安银座商城有限公司913709007262092842杭州九阳生活电器有限公司2022.11.23/-K17-F10Joyoung九阳合格山东省计量科学研究院
23电水壶流通领域银座集团股份有限公司济南银座燕山购物广场91370100677261966E飞利浦家电（中国）投资有限公司230202/230323/-HD9316PHILIPS合格山东省计量科学研究院
24电水壶流通领域银座集团股份有限公司济南银座燕山购物广场91370100677261966E诺斯凯其（上海）家用电器有限公司2021.12.20/-NS-C01GWNOSSCACH诺斯凯其合格山东省计量科学研究院
25电热水壶（开水煲）流通领域银座集团股份有限公司聊城银座商城91371500694428078X杭州九阳生活电器有限公司2022.12.9/202210.18/-K20FD-W730九阳合格山东省计量科学研究院
26电热水壶（开水煲）流通领域银座集团股份有限公司聊城银座商城91371500694428078X杭州九阳生活电器有限公司2021.12.20/2022.1.2/-K15FD-W330九阳合格山东省计量科学研究院
2023年电热水壶产品质量省级监督抽查未抽到企业名单序号企业名称抽查状态1金镶玉茶文化股份有限公司该企业无生产线，仓库无本次所抽待售产品2九阳股份有限公司企业该厂址无库存产品3青岛沸腾科技有限公司暂时停产4青岛海尔成套家电服务有限公司该企业产品全部委托其他企业生产，本地址无生产线、无库存5青岛海尔智慧生活电器有限公司该企业产品全部委托其他企业生产，本地址无生产线、无库存6青岛思之源环保科技有限公司产品仅在潮州工厂代工生产，现场也无库存7日照同菲电器科技有限公司停产8山东黄帝内经健康管理集团有限公司企业注册地点仅为办公场所，无仓库及生产线，并且该企业所具备的相关产品证书处于暂停状态9山东康宏电器有限公司停产10山东小鸭集团小家电有限公司该公司所在地址仅为办公地址，无生产线与仓库，不在此处进行生产活动11山东耘威医疗科技有限公司无符合监督抽查实施细则要求的产品12山东鑫霁康生物科技有限公司注册地无生产线，无仓库以及所涉及产品的库存13威海瑞沐精工科技有限公司暂时停产14潍坊市潍星电器有限公司暂时停产15淄博奢瓷经贸有限公司无符合监督抽查实施细则要求的产品
2.怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复
怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复
璐姐总结：
服务可靠性的核心是：容灾，不过挺实用的，这个是个大话题，如果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并发更新缓存也没有问题 – 廖强
怎么个死法。。缓存失效的时候去下游更新数据的时候第一进程加个一分钟或者两分钟有效的缓存锁，更新完数据删除。其他进程查询这个锁里面有值就先不更新。如果第一个进程更新失败了导致锁没有删除，等锁自动失效其他进程再更新。 – 荣亮
都是热，但是不同的两种热，如果是热更新，另一个是热查询 – 老王
正常的缓存策略不存在更新一说，要么是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
。。。。 果然是没用引号的问题。。
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
这个确实是个问题，我们的分库策略很简单，有一个库记录了<id,库>的对应关系 – smargo
rpc 一般只会实现比较通用的调度策略，比如 round bin 还有根据注册中心的 weight 值，你这种调 rpc 还得查一下数据库的建议不要和 rpc 做在一起 – yangmls
大家有人关注过 tidb 么？ – 崔秋@PingCAP
有,我正在读tidb的源码 – 廖强
这个一致性和故障恢复的场景，其实是 tidb 这种类型的 newsql 数据库最擅长解决的问题 – 崔秋@PingCAP
嗯，tidb的解决方案和我之前写的类似，区别在于我是在mysql源码基础上做的，然后在外面包了一个协调者,之前做的也比较有限，现在看有人让sql的解释引擎做成分布式的，这个当时没有涉及太深。当时基本还是延用mysql的sql解释器 – 廖强
传统的 mysql 或者 mysql 中间件因为架构上的问题，在这方面都没有彻底完善的方案，这方面是需要新的架构和算法来保证的，所以必须从根本上进行创新，要么修改 mysql 源码，要么就重造一个，基本上没有其他的方法,semi sync 本身在某些场景下也会退化成异步，本质上还是会有丢数据的风险的，所以从理论上来说并不能保证数据的一致性的 – 崔秋@PingCAP
很早之前mysql考虑这个事情，所以他支持了XA协议，但是内部里面的实现只支持了单机跨事务引擎的强一致性，把binlog作为2阶段提交的协调者。这个很坑,对，存在退化成异步的可能，要做的话，目前能想到的基本跟oceanbase的思路一致了 – 廖强
分布式事务暂时也没有什么好的办法，基本主流的做法绕不开 2pc， 剩下就看工程实现了，比如可以考虑 batch write， batch read， txn scheduler 的工程实现了，感觉都是有性能瓶颈了，所以有分布式的需求，那基本上只能试用高吞吐的场景，不适用于低延迟。 – 崔秋@PingCAP
一直关注tidb，想未来这个db稳定了，可以用到业务场景中去，目前还算看好。上次你们的创始人发微博嘲讽了一下mysql，引来了何登成的“反击”，哈哈。嗯，差不多就那些工程方法了，主流的做法都差不多，主要看细节了 – 廖强
性能测试本来很多时候都是 bench marketing，主要 dongxu 就是那种随性的人，你们有空见下就知道了，也不是嘲讽 – 崔秋@PingCAP
哈哈，还想着看看有没有机会成为tidb的commitor呢 – 廖强
感谢大家对 TiDB 的关注啊 任何数据库都不是银弹，主要看它特点是什么，能带来什么价值，帮大家解决什么问题，才是最重要的,现在 TiDB 文档其实不是太完善，而且有些文档都比较过期了，包括部署试用搞起来都没那么顺滑，所以给大家深入了解这个项目带来了很多困扰，抱歉了 ,大家继续聊技术吧，技术本身才是最核心的，至于是什么数据库，只要能解决现有问题的就是好的数据库 – 崔秋@PingCAP
内个TiDB会不会跟ssdb一样，搞个半成品给人用，后面无人维护啊,我们有业务用了ssdb，发现几次数据丢失 – tiyee
不会啊，如果用 tidb 的话，我们全力 support @tiyee – 崔秋@PingCAP
【今日分享】
如何评价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 ]
【其他】
文章来源：黑夜路人技术讨论群
如有疑问或异议，请加群讨论
加群请关注公众号：“黑夜路人技术” ，回复加群
3.怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复
怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复
璐姐总结：
服务可靠性的核心是：容灾，不过挺实用的，这个是个大话题，如果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并发更新缓存也没有问题 – 廖强
怎么个死法。。缓存失效的时候去下游更新数据的时候第一进程加个一分钟或者两分钟有效的缓存锁，更新完数据删除。其他进程查询这个锁里面有值就先不更新。如果第一个进程更新失败了导致锁没有删除，等锁自动失效其他进程再更新。 – 荣亮
都是热，但是不同的两种热，如果是热更新，另一个是热查询 – 老王
正常的缓存策略不存在更新一说，要么是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
。。。。 果然是没用引号的问题。。
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
这个确实是个问题，我们的分库策略很简单，有一个库记录了<id,库>的对应关系 – smargo
rpc 一般只会实现比较通用的调度策略，比如 round bin 还有根据注册中心的 weight 值，你这种调 rpc 还得查一下数据库的建议不要和 rpc 做在一起 – yangmls
大家有人关注过 tidb 么？ – 崔秋@PingCAP
有,我正在读tidb的源码 – 廖强
这个一致性和故障恢复的场景，其实是 tidb 这种类型的 newsql 数据库最擅长解决的问题 – 崔秋@PingCAP
嗯，tidb的解决方案和我之前写的类似，区别在于我是在mysql源码基础上做的，然后在外面包了一个协调者,之前做的也比较有限，现在看有人让sql的解释引擎做成分布式的，这个当时没有涉及太深。当时基本还是延用mysql的sql解释器 – 廖强
传统的 mysql 或者 mysql 中间件因为架构上的问题，在这方面都没有彻底完善的方案，这方面是需要新的架构和算法来保证的，所以必须从根本上进行创新，要么修改 mysql 源码，要么就重造一个，基本上没有其他的方法,semi sync 本身在某些场景下也会退化成异步，本质上还是会有丢数据的风险的，所以从理论上来说并不能保证数据的一致性的 – 崔秋@PingCAP
很早之前mysql考虑这个事情，所以他支持了XA协议，但是内部里面的实现只支持了单机跨事务引擎的强一致性，把binlog作为2阶段提交的协调者。这个很坑,对，存在退化成异步的可能，要做的话，目前能想到的基本跟oceanbase的思路一致了 – 廖强
分布式事务暂时也没有什么好的办法，基本主流的做法绕不开 2pc， 剩下就看工程实现了，比如可以考虑 batch write， batch read， txn scheduler 的工程实现了，感觉都是有性能瓶颈了，所以有分布式的需求，那基本上只能试用高吞吐的场景，不适用于低延迟。 – 崔秋@PingCAP
一直关注tidb，想未来这个db稳定了，可以用到业务场景中去，目前还算看好。上次你们的创始人发微博嘲讽了一下mysql，引来了何登成的“反击”，哈哈。嗯，差不多就那些工程方法了，主流的做法都差不多，主要看细节了 – 廖强
性能测试本来很多时候都是 bench marketing，主要 dongxu 就是那种随性的人，你们有空见下就知道了，也不是嘲讽 – 崔秋@PingCAP
哈哈，还想着看看有没有机会成为tidb的commitor呢 – 廖强
感谢大家对 TiDB 的关注啊 任何数据库都不是银弹，主要看它特点是什么，能带来什么价值，帮大家解决什么问题，才是最重要的,现在 TiDB 文档其实不是太完善，而且有些文档都比较过期了，包括部署试用搞起来都没那么顺滑，所以给大家深入了解这个项目带来了很多困扰，抱歉了 ,大家继续聊技术吧，技术本身才是最核心的，至于是什么数据库，只要能解决现有问题的就是好的数据库 – 崔秋@PingCAP
内个TiDB会不会跟ssdb一样，搞个半成品给人用，后面无人维护啊,我们有业务用了ssdb，发现几次数据丢失 – tiyee
不会啊，如果用 tidb 的话，我们全力 support @tiyee – 崔秋@PingCAP
【今日分享】
如何评价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 ]
【其他】
文章来源：黑夜路人技术讨论群
如有疑问或异议，请加群讨论
加群请关注公众号：“黑夜路人技术” ，回复加群
4.怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复
怎么保证服务可靠性、数据一致性、以及一旦宕机数据恢复
璐姐总结：
服务可靠性的核心是：容灾，不过挺实用的，这个是个大话题，如果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并发更新缓存也没有问题 – 廖强
怎么个死法。。缓存失效的时候去下游更新数据的时候第一进程加个一分钟或者两分钟有效的缓存锁，更新完数据删除。其他进程查询这个锁里面有值就先不更新。如果第一个进程更新失败了导致锁没有删除，等锁自动失效其他进程再更新。 – 荣亮
都是热，但是不同的两种热，如果是热更新，另一个是热查询 – 老王
正常的缓存策略不存在更新一说，要么是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
。。。。 果然是没用引号的问题。。
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
这个确实是个问题，我们的分库策略很简单，有一个库记录了<id,库>的对应关系 – smargo
rpc 一般只会实现比较通用的调度策略，比如 round bin 还有根据注册中心的 weight 值，你这种调 rpc 还得查一下数据库的建议不要和 rpc 做在一起 – yangmls
大家有人关注过 tidb 么？ – 崔秋@PingCAP
有,我正在读tidb的源码 – 廖强
这个一致性和故障恢复的场景，其实是 tidb 这种类型的 newsql 数据库最擅长解决的问题 – 崔秋@PingCAP
嗯，tidb的解决方案和我之前写的类似，区别在于我是在mysql源码基础上做的，然后在外面包了一个协调者,之前做的也比较有限，现在看有人让sql的解释引擎做成分布式的，这个当时没有涉及太深。当时基本还是延用mysql的sql解释器 – 廖强
传统的 mysql 或者 mysql 中间件因为架构上的问题，在这方面都没有彻底完善的方案，这方面是需要新的架构和算法来保证的，所以必须从根本上进行创新，要么修改 mysql 源码，要么就重造一个，基本上没有其他的方法,semi sync 本身在某些场景下也会退化成异步，本质上还是会有丢数据的风险的，所以从理论上来说并不能保证数据的一致性的 – 崔秋@PingCAP
很早之前mysql考虑这个事情，所以他支持了XA协议，但是内部里面的实现只支持了单机跨事务引擎的强一致性，把binlog作为2阶段提交的协调者。这个很坑,对，存在退化成异步的可能，要做的话，目前能想到的基本跟oceanbase的思路一致了 – 廖强
分布式事务暂时也没有什么好的办法，基本主流的做法绕不开 2pc， 剩下就看工程实现了，比如可以考虑 batch write， batch read， txn scheduler 的工程实现了，感觉都是有性能瓶颈了，所以有分布式的需求，那基本上只能试用高吞吐的场景，不适用于低延迟。 – 崔秋@PingCAP
一直关注tidb，想未来这个db稳定了，可以用到业务场景中去，目前还算看好。上次你们的创始人发微博嘲讽了一下mysql，引来了何登成的“反击”，哈哈。嗯，差不多就那些工程方法了，主流的做法都差不多，主要看细节了 – 廖强
性能测试本来很多时候都是 bench marketing，主要 dongxu 就是那种随性的人，你们有空见下就知道了，也不是嘲讽 – 崔秋@PingCAP
哈哈，还想着看看有没有机会成为tidb的commitor呢 – 廖强
感谢大家对 TiDB 的关注啊 任何数据库都不是银弹，主要看它特点是什么，能带来什么价值，帮大家解决什么问题，才是最重要的,现在 TiDB 文档其实不是太完善，而且有些文档都比较过期了，包括部署试用搞起来都没那么顺滑，所以给大家深入了解这个项目带来了很多困扰，抱歉了 ,大家继续聊技术吧，技术本身才是最核心的，至于是什么数据库，只要能解决现有问题的就是好的数据库 – 崔秋@PingCAP
内个TiDB会不会跟ssdb一样，搞个半成品给人用，后面无人维护啊,我们有业务用了ssdb，发现几次数据丢失 – tiyee
不会啊，如果用 tidb 的话，我们全力 support @tiyee – 崔秋@PingCAP
【今日分享】
如何评价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 ]
【其他】
文章来源：黑夜路人技术讨论群
如有疑问或异议，请加群讨论
加群请关注公众号：“黑夜路人技术” ，回复加群
