小哨兵一键恢复(UCloud优刻得数字哨兵升级九大核验功能；吉利成立数字科技公司 | 36氪大公司数字创新指南0512)
小哨兵一键恢复文章列表:
- 1、UCloud优刻得数字哨兵升级九大核验功能；吉利成立数字科技公司 | 36氪大公司数字创新指南0512
- 2、奉贤这个4A景区即将开门营业 奉浦快线等公交已恢复运营
- 3、本土新增+2，沪逐步恢复进京列车！上海旅客进入杭州，记者亲历健康码变化过程
- 4、钢铁侠骂骂咧咧退出群聊！漫威宇宙的超强机器人：哨兵
- 5、一文带你了解Redis哨兵模式和高可用集群解析万字长文
UCloud优刻得数字哨兵升级九大核验功能；吉利成立数字科技公司 | 36氪大公司数字创新指南0512
作者|王耐，真梓；编辑|石亚琼
36氪ToB产业组推出了新板块“大公司数字化创新指南”，我们会为大家汇总每日各行业大公司数字化创新业务的主要新闻。
5月12日大公司数字化创新行业动态日报请查收：
UCloud优刻得“数字哨兵”升级九大核验功能
近日，UCloud优刻得AI团队技术人员推出了新一代AI“数字哨兵”一体机产品。UCloud优刻得“数字哨兵”对接上海市大数据中心的调用接口，具备健康数据实时核验功能，可实现“无接触快速测温、健康码状态核验、核酸信息核验、抗原信息核验、疫苗信息核验、身份证快速健康核验、人证一致性核验、社保卡快速健康核验、人脸识别快速健康核验”等九大防疫功能，可以帮助企业通过立柱、手持机等终端设备，用于园区门口的闸机、门禁、进出车辆核验，还可以与考勤和安防系统对接，帮助企业快速实现复工复产。目前，UCloud优刻得“数字哨兵”，已经在杨浦区机关服务中心、虹口和普陀区医疗保险事务中心、中建八局、临港自贸区、我格广场等政府、公共服务机构、企业园区、人流密集场所完成部署。
《UCloud优刻得“数字哨兵”升级九大核验功能 助力企业生产秩序恢复》
吉利成立数字科技公司
据天眼查消息，近日，浙江吉利数字科技有限公司成立，法定代表人为柏林森，注册资本3亿人民币，经营范围包括软件开发；软件外包服务；信息技术咨询服务；企业总部管理；企业管理（除依法须经批准的项目外，凭营业执照依法自主开展经营活动）。股东信息显示，该公司由浙江吉利控股集团有限公司全资控股。
《吉利3亿成立数字科技公司》
韩国计划明年颁布《数字资产基本法》
根据韩国总统过渡委员会的“国家任务实施计划”，韩国候任总统尹锡悦的新政府已制定政策，准备在今年内制定《数字资产基本法》的政府计划，并计划于明年颁发，2024年实施。此前消息，韩国总统过渡委员会公布了110项政府任务提案，其中包括推动《数字资产基本法》监管。目前，《数字资产基本法》的制定正等待国会通过，韩国新政府还计划制定一项反映国际组织和主要国家监管讨论的政府法案。在制定数字资产框架法案时，国际清算银行（BIS）、金融稳定委员会（FSB）以及美国和欧盟（EU）监管机构将推动积极合作并建立合作机制系统。
除了立法，韩国新政府还将准备一个基础设施。在此过程中，虚拟资产交易账户发行机构有望扩大。过渡委员会表示：“我们将通过扩大为虚拟交易提供实名认证服务的金融机构，加强数字资产交易账户与银行之间的联系。”
《韩国计划明年颁布》
浙江省使用数字人民币支付县级医院落地龙港
5月12日上午，浙江省龙港市人民医院举行数字人民币试点启动仪式，成为浙江省首家使用数字人民币支付的县级医院。据介绍，数字人民币和硬币纸钞一样，都是央行发行的法定货币，顾名思义，以数字形式存在。它和硬币纸钞等价，主要用于替代流通中的现金。数字人民币支持双方离线支付，无网络也可实现交易，方便快捷，拓宽了患者就医支付渠道，缴费安全性也能够得到保障。
《无网络也可支付！浙江省首家使用数字人民币支付县级医院落地龙港》
奉贤这个4A景区即将开门营业 奉浦快线等公交已恢复运营
东方网记者奚亮5月16日报道：今天上午，记者从奉贤区政府获悉，奉贤区内的上海之鱼、古华公园等公园已恢复开放，碧海金沙也将于5月18日实行分时预约措施，安排游客入园。
为 逐步有序恢复正常生产生活秩序，奉贤区决定在5月17日、19日、21日开展全员核酸检测，16日、18日、20日开展封控区、管控区及重点人群核酸检测。
同时，按照“有序放开、有限流动、有效管控、分类管理”的原则，奉贤区部分公交、公园（含AAAA级景区）、公共商超、公共街区在严格落实疫情防控措施的前提下，将实行限时、限流运行。
据记者了解，今天奉贤区内的部分公交线路已恢复区内运营，如南团快线、奉浦快线区间（南桥汽车站至南行港路站）、奉贤1路、奉贤15路、奉贤17路、奉贤23路、奉贤24路、奉贤25路、882路区间（南桥汽车站至邬桥站），其营运时间为7：00至18：00，后续公交线路恢复将视疫情防控情况，逐步有序恢复运营。
此外，自今天起，上海之鱼、古华公园将有序恢复开放（园内室内场馆、游乐设施等暂不开放），公园开放时间暂定为8:00至17:00。
作为国家AAAA级景区，碧海金沙景区将于2022年5月18日起逐步有序恢复正常营业（园内室内场所、游乐设施暂不开放）。
需要注意的是，无论是乘坐公共交通还是入园游览，都需要正确佩戴口罩，自觉接受体温检测，提供48小时内核酸检测阴性证明，主动扫码或经数字哨兵验证。
疫情防控期间，各公园也将严格管控游客数量，实行“限量、错峰”管理，游客规模不应超过最大承载量的50%；游客高峰时及时预警，采取必要的限流措施。
需要提醒的是，疫情防控管理措施，市民还需时刻保持个人防护意识，不扎堆、不聚集，共同营造卫生、安全、有序的环境。
来源： 东方网
本土新增+2，沪逐步恢复进京列车！上海旅客进入杭州，记者亲历健康码变化过程
2022年7月2日0—24时，新增本土新冠肺炎确诊病例2例，均在隔离管控中发现。新增境外输入性新冠肺炎确诊病例5例和无症状感染者7例，均在闭环管控中发现。
本土病例情况
2022年7月2日0—24时，新增本土新冠肺炎确诊病例2例。治愈出院1例。
病例1，39岁，
病例2，33岁，
均为航司国际航班入境服务保障人员。7月1日，在闭环管理期间例行检测发现结果异常，2人即被隔离排查。经市、区疾控中心复核，核酸检测结果为阳性。经市级专家会诊，综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为确诊病例。
本土无症状感染者情况
2022年7月2日0—24时，无新增本土无症状感染者。
境外输入病例情况
2022年7月2日0—24时，通过口岸联防联控机制，报告5例境外输入性新冠肺炎确诊病例。治愈出院5例，其中来自美国2例，来自几内亚1例，来自以色列1例，来自英国1例。
病例1为阿根廷籍，在阿根廷生活，自阿根廷出发，经德国转机，于2022年6月21日抵达上海浦东国际机场，入关后即被集中隔离观察，其间出现症状。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为确诊病例。
病例2为中国籍，在英国留学，自英国出发，经丹麦转机，于2022年6月22日抵达上海浦东国际机场，入关后即被集中隔离观察，其间出现症状。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为确诊病例。
病例3为墨西哥籍，在墨西哥探亲，自墨西哥出发，经加拿大转机，于2022年6月27日抵达上海浦东国际机场，入关后即被集中隔离观察，其间出现症状。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为确诊病例。
病例4为中国籍，在英国留学，自英国出发，经德国转机，于2022年6月28日抵达上海浦东国际机场，入关后即被集中隔离观察，其间出现症状。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为确诊病例。
病例5为中国籍，在秘鲁工作，自秘鲁出发，经荷兰转机，于2022年6月29日抵达上海浦东国际机场，入关后即被集中隔离观察，其间出现症状。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为确诊病例。
5例境外输入性确诊病例已转至定点医疗机构救治，已追踪同航班密切接触者14人，均已落实集中隔离观察。
境外输入性无症状感染者情况
2022年7月2日0—24时，新增境外输入性无症状感染者7例。
无症状感染者1为中国籍，在英国留学，自英国出发，经德国转机，于2022年6月28日抵达上海浦东国际机场，入关后即被集中隔离观察，其间例行核酸检测异常。经排查，区疾控中心新冠病毒核酸检测结果为阳性。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为无症状感染者。
无症状感染者2为中国籍，在加纳工作，自加纳出发，经荷兰转机，于2022年6月29日抵达上海浦东国际机场，入关后即被集中隔离观察，其间例行核酸检测异常。经排查，区疾控中心新冠病毒核酸检测结果为阳性。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为无症状感染者。
无症状感染者3为中国籍，在阿根廷工作，自阿根廷出发，经德国转机，于2022年6月30日抵达上海浦东国际机场，入关后即被集中隔离观察，其间例行核酸检测异常。经排查，区疾控中心新冠病毒核酸检测结果为阳性。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为无症状感染者。
无症状感染者4为中国籍，在美国旅行，自美国出发，于2022年6月30日抵达上海浦东国际机场，入关后即被集中隔离观察，其间例行核酸检测异常。经排查，区疾控中心新冠病毒核酸检测结果为阳性。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为无症状感染者。
无症状感染者5为中国籍，在加拿大留学，自加拿大出发，于2022年7月1日抵达上海浦东国际机场，入关后即被集中隔离观察，其间例行核酸检测异常。经排查，区疾控中心新冠病毒核酸检测结果为阳性。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为无症状感染者。
无症状感染者6、无症状感染者7均为中国籍，在英国留学，自英国出发，经芬兰转机，乘坐同一航班，于2022年7月1日抵达上海浦东国际机场，入关后即被集中隔离观察，其间例行核酸检测异常。经排查，区疾控中心新冠病毒核酸检测结果为阳性。综合流行病学史、临床症状、实验室检测和影像学检查结果等，诊断为无症状感染者。
7例境外输入性无症状感染者已转至定点医疗机构医学观察，已追踪同航班密切接触者123人，均已落实集中隔离观察。
“摘星”后
上海人去杭州更方便了吗？
这两天，上海两位记者
分别通过乘高铁和自驾两种方式
到达杭州
来看他们的体验
↓
乘高铁
7月1日，记者从上海乘坐高铁进入杭州，亲历健康码的变化过程。
进入杭州后，首先有专门的防疫人员甄别旅客的来源地。上海游客会被带到一个单独的通道，进行流调和核酸检测。
杭州站到处都贴着巨大的扫码通行标志，提醒游客扫码。值得一提的是，只有支付宝可以扫，微信是不可以的。
记者在前一天的下午已经在上海做过核酸检测，还在24小时之内的有效期，但是在杭州扫完场所码以后，健康码上的核酸检测板块显示为灰色，提示超过7日没有进行核酸检测。和核酸检测模块并排的是一个红色感叹号，提示曾经到过疫情重点地区，需要进行核验。
在被带到专门的留待通道以后，首先出现的“码”是上城区的“一码报”系统。扫描这个码进去，填写疫情防控承诺书。
填完这个承诺书以后，进入下一个环节，进行抗原检测。抗原检测的试剂盒都被放在一排长条桌的盒子里，游客自取自助，进行抗原检测。杭州的抗原检测看起来比较高端，可以快速出结果，时间大约为1分钟左右。
在抗原检测显示正常以后，便可以用身份证扫码通过闸机，进入到核酸检测的通道。
核酸检测的桌子旁边有一个篮子，里面放着一堆的粉色纸条，拿上纸条，做完核酸，再到出口闸机处，用粉色纸条和自己的身份证一起合影，证明自己已经进行过核酸检测，然后刷身份证出留观区。
出留观区以后再去坐地铁，疫情防控人员都会看这张合影。在核酸检测结果出来之前，去所有的场所，刷码出现感叹号以后，疫情防控人员都会要求看这张纸条证明已经做过核酸。
记者在随后进入杭州大厦，杭州地铁，杭州的公交车等各类公共场所，都需要用支付宝扫场所码，不支持微信扫码。
自驾
昨天一早，记者从广播大厦出发前往杭州，途经高速公路及道口，先后抵达杭州市内景区、餐厅和商超，实地感受运营状态与实施的防疫措施。
出行路线：广播大厦-G60沪昆高速-经停嘉兴长安服务区-由德胜收费站进入杭州市-前往杭州市上城区西湖景区
9:00：不停车通过G60沪昆高速沪浙道口，顺利进入浙江省境内。
9:45：途经G60沪昆高速嘉兴市长安服务区，进入洗手间和餐饮服务区需扫码登记，显示绿码后通过数字哨兵验码即可进入。
10:20：抵达G60沪昆高速杭州主线收费站，缴费后进行防疫检查，签署承诺书后放行。
11:30：抵达杭州市上城区，进商场停车库，停车后进入商场只进行了一次体温检测，但进入餐厅后会被要求扫描场所码，显示绿码后可入座，若非绿码则拒绝接待。
13:00：记者来到西湖景区，虽然气温较高，但依然有不少游客在湖边散步游玩，景区景点处于全面开放，没有限制，在景区附近还设有便民核酸检测站，但开放时间有限。
记者先后前往一家星级酒店和一家快捷酒店咨询，对上海抵杭的住客，均要求出示48小时内核酸阴性证明，并扫码为绿码即可办理入住。其中，星级酒店会以街镇为单位，确认住客是否来自中高风险地区的街镇，不涉及即可入住。
需要提醒的是，防疫政策动态变化，有入住需求的市民，建议出行前电话咨询酒店，提前进行确认。
体验后的建议：杭州不少公共场所和搭乘公共交通时都需出示带有核酸结果的健康码，但并不显示异地核酸检测结果。所以，为了有更好的出行体验，建议抵达杭州后可先去当地做个核酸检测，待检测结果出来后，便可实现一码通。
值得注意的是：
上海静安、奉贤等地游客
去杭州或需报备
（点击查看详情↑）
如果出行的话
仍需注意做好防护！
7月2日起
上海地区逐步恢复开行进京列车
据铁路上海站官微消息，7月2日起，上海地区逐步恢复开行进京列车。具体开行列车时刻如下：
铁路客票预售期15天（含当天），需要购票的旅客可以通过铁路12306官网、12306手机App、拨打95105105电话订票热线或到车站售票窗口购买。
温馨提醒：进京旅客仍需查验“北京健康宝”绿码和48小时内核酸阴性证明。为了不耽误您的出行，请提前做好准备。
综合健康上海12320、上观新闻、上海交通广播、第一财经、杭州日报等
来源： 东方网
钢铁侠骂骂咧咧退出群聊！漫威宇宙的超强机器人：哨兵
哨兵是在漫威宇宙中被设计来狩猎变种人的各类机器人，它们通常被描绘为X-Men的敌人，漫画裡初次登场是在X-Men (vol. 1) #14 (1965年11月) 。哨兵最初是由Bolivar Trask博士创造，打算用以从他视为威胁物种生存的变种人手中拯救人类。哨兵有著先进的科技，并已展现出多样的能力；他们的主要武装为能量武器和束缚装置，能够飞行，并且从远距离侦测变种人。他们有著巨大的力气，身体能够高度抵御伤害；有些哨兵还能够改变自身的物理型态，或是在被摧毁后重新组装和启动。哨兵可以从经验中学习，在参与过程中发展自身的防御能力。大量的哨兵机器人是由一名被称做母体模组 (Master Mold) 的巨大哨兵所创造和领导。
历代主要哨兵机型：
哨兵Mark I
由Bolivar Trask博士创造的第一代哨兵，初登场于X-Men (vol. 1) #14。除了飞行能力之外，Mark I可以从胸口发射等离子、电子、昏迷射线和高热等能量，还配备有粉碎装置，用来分解无机物质；它们有能力藉由扫描周遭地区所有生物，识别人类或是变种人。Mark I初次在电视亮相时，在Master Mold的命令下，失控绑架了它们的发明者，企图创造一支军队征服人类世界。Bolivar Trask意识到自己的错误——并非所有变种人皆会使用他们的力量为非作歹，他最终牺牲自己的性命摧毁了哨兵的製造设施与母体模组。
哨兵Mark II
由Larry Trask创造，初登场于X-Men (vol. 1) #57。儘管Bolivar Trask理解到并非所有变种人皆是人类的威胁，最终牺牲性命摧毁自己的创造物，然而他的儿子Larry却将父亲的死怪罪于X-Men，决定根据父亲在基地留下的设计，创造新型的哨兵机器人追踪和囚禁X-Men与其他变种人。Mark II拥有自我修复机能，可藉由人类戴上特殊的控制盔从远端遥控。它们有能力分析超人异能和武器，在数秒内发展出对抗的方法，随后这项资讯也会传达给所有其他哨兵。在追捕X-Men的过程中，独眼龙成功欺骗并说服哨兵寻求和摧毁人类突变的源头——太阳。当得知自身的火力不足以摧毁太阳，它们决定转而控制太阳辐射，製造闪焰毁灭人类，终止变种人的诞生，然而这个计画最终也被复仇者阻止。
哨兵Mark III (X-Sentinels)
由Stephen Lang博士创造，初登场于X-Men (vol. 1) #98。在Larry Trask死后，哨兵计画留下的资产落入了美国政府手中，Stephen Lang博士成为联邦研究变种人的新负责人；身为反变种人的盲信者，他利用自己的职位获取Trask的笔记和设计，提供他创造新型哨兵的基础。不幸地由于只拥有不完整的笔记，哨兵Mk III的性能和智慧并不如先前的机型，值得注意的是，它们的外型、声音、战斗方式皆被打造成如同原版的X-Men，被称为X-Sentinels，并且在一定程度上模仿了本人的力量；此外，Mark III还可以生成足以容纳六人尺寸的气泡，在太空运送生物。它们成功地混淆了X-Men的成员，然而，随后金钢狼识破这些冒牌货并非人类，揭露出它们真实的本质，并且成功击败了X-Sentinels。
哨兵Mark IV-VII
当邪恶变种人兄弟会企图在参议员Senator Robert进行一场关于超人类与变种人的潜在威胁的演说场合上刺杀他以后，总统内阁授权了机密与非法的研究——完全清醒计画 (Project Wideawake) ，捕捉任何可能威胁国家安全的超能变种人，计画的负责人为Henry Gyrich。政府联繫了工业大亨Sebastian Shaw，忽略他本身是邪恶变种人的事实，为计画打造新品种的哨兵。Sebastian Shaw生产了三种机型：Mark IV、Mark V、和Mark VI；这三种机型被证实未能比得上Mark II或Mark III哨兵，依然持续进行著改良。Shaw秘密透过哨兵来攻击自己的敌人X-Men，但政府未能意识到这一点。
Mark IV初登场于X-Men (vol. 1) #151，可以通过手腕的电缆来攻击，眼部配备有搜索灯。它们拥有独特的学习程式，经过至少一分钟的分析，能够使该架Mark IV在与敌人战斗时取得优势，这些数据可被储存用以在将来面对相同的敌人，任何同型的哨兵皆可取得这些数据，然而，数据的修改需要花上至少一周的时间。Mark V初登场于New Mutants (vol. 1) #2，这个机型的不同之处在于除了能够发射等离子、电子、催眠瓦斯和高热之外，它们的眼部可以喷出液态氮，困住冻结成茧的对手。Mark VI初登场于New Mutants (vol. 1) #48，这个机型增加了隐形机能，植入液晶使它们在肉眼和雷达上皆不可视。之后，同样由Shaw工业生产的Mark VII初登场于X-51 (vol. 1) #7，Sebastian Shaw修改了哨兵程式用以捕捉机器人X-51，此机型可以从远端遥控。
哨兵Mark VIII (Sentinel Squad O*N*E)
由史塔克企业设计，初登场于All-New X-Factor (Vol 1) #15。作为美国政府努力稳定自M-Day以来变种人处境的项目之一，国家应急办公室 (O*N*E) 提议恢复及重组哨兵计画。为此，O*N*E联繫史塔克工业升级现有的哨兵，同时在进攻和防守上取得神盾局的改良，产生以人类驾驶员操作的新品种的哨兵设计。这组哨兵的独一无二之处在于不同于传统的机械哨兵，它们需要驾驶，目前小组是由James Rhodes（战争机器）进行训练。哨兵小队计画尽力训练出新世代可控、可靠、可修复、可替换、可订製、以及忠诚的美国英雄，接受O*N*E的管理和军事指挥组织的训练。它们被部属在X宅邸保护变种人，同时阻止变种人的革命活动。
史塔克型哨兵 (Stark Sentinels)
由Tony Stark设计，初登场于Avengers & X-Men: AXIS (Vol 1) #1。在窃取Charles Xavier的大脑后，红骷髅洗脑Tony Stark设计新型的哨兵帮助他清除世上的超人类。以亚德曼金属打造的外壳，加上Tony根据他在内战时取得的不同英雄的知识进行设计，史塔克型哨兵有能力对抗目标的长处，并且将敌人沐浴在皮姆粒子中，缩小并且囚禁他们。然而，由于史塔克型哨兵的设计均来自Tony关于超级英雄的档案，因此它们无法对抗多数罪犯。儘管在无太大困难下，它们很快地制伏了复仇者和X-Men，却在万磁王集结的超级罪犯的协助下被击败。
野生型哨兵 (Wild Sentinels)
野生型哨兵是美国在厄瓜多所资助的计画——开发不断进化和自我维持的哨兵——的成果，初登场于New X-Men (Vol 1) #114。野生型哨兵的母体模组是由Bolivar Trask所设计，目的是清除测试范围内所有科技和物质，打造出一支军队。Cassandra Nova拷贝Donald Trask III（Bolivar Trask的外甥）的DNA来下令母体模组放弃原来的任务，将两架体型巨大、拥有高度适应性的野生型哨兵派往攻击变种人的家园Genosha，这场攻击导致几乎所有岛屿上居民大约1600万人的死亡，后来其中一架被危境 ( Danger) 赋予了意识。
至尊型哨兵 (Prime Sentinels)
棱堡在启动零容忍行动 (Operation: Zero Tolerance) 计划时创造，初登场于X-Men (Vol 2) #65。这些哨兵事实上是由人类植入纳米科技，激活后，将人类并转化为带有强大武器系统的武装生物。这些被改造的人类被设置为潜伏的间谍，不知晓自己的本质，直到零容忍行动的信号启动他们的程式。至尊型哨兵配备有数种能力，如飞行、超级力量、射线，以及能够抑制和扰乱周遭的变种能力，他们的程式可能使用原宿主的人格，诱骗不知情的目标进入交谈。他们被棱堡用来捕捉X教授，攻击全国境内与X-Men有关联的各个变种人，棱堡和他的至尊型哨兵最终在神盾局的协助下被X-Men击败，终结了零容忍行动。
宁录型哨兵 (Nimrod Sentinels)
初登场于X-Men: Legacy (Vol 1) #236。作为棱堡和人类理事会 (Human Council) 猎杀弥赛亚之子以及毁灭人类计画的一部分，巨大的穹顶出现在旧金山湾区，切断了X-Men逃生的去路。一旦穹顶启动，棱堡打开了通往他故乡分歧现实的维度入口，使得大量的宁录系列哨兵涌入这世界。如同原版的宁录，这些哨兵能够侦测、分析与适应变种能力，还能自我修复，X-Men在产生大量伤员下仅能勉强击退它们，然而每间隔5分钟，便有新一波宁录型哨兵从通道口现身，唯有将X-Force成员、Cable和Cypher送往未来重写以及摧毁宁录型哨兵的母体模组，X-Men才得以战胜。
母体模组 (Master Mold)
初登场于X-Men (Vol 1) #15。母体模组是由Bolivar Trask创造以用来建立一支MK I哨兵军队，控制变种人族群，最初版本的母体模组在哨兵总部被X-Men破坏之时被摧毁。经过Trask的死亡，美国政府将哨兵计画的指挥交付给Stephen Lang，地狱火俱乐部提供他资金援助，却不知晓他妄想杀死所有变种人的念头，他重建了母体模组，却未使用它。直到X-Men摧毁了Lang与哨兵所在的太空站，脑死的Lang将自己的记忆备份于母体模组的电脑，母体模组因此认定自己是Lang本人。母体模组有著Mk I和Mk III哨兵的所有武器，他的大脑单元可以拆卸与自我修复，由于拥有Lang的记忆，它精通电子和机器人学，得以建造不同种类的机器人。
宁录 (Nimrod)
初登场于Uncanny X-Men (Vol 1) #191。在未来昔日的替代未来裡，哨兵控制了整个北美，宁录则作为最先进的原型机被製造出来。在执行破坏宁录计画的任务中，Rachel Summers与Kate Pryde被刚启动的宁录型哨兵发现，Rachel最终透过传送回到过去，但是宁录杀死了Kate，并试图跟随Rachel回到过去。宁录的身体是由高度强度的材料构成，可以改变尺寸和外观，伪装成人类；它可以直接控制身体构造的任一部分，重新排列内部零件来更好地使用武装和功能，自动修复损毁的装甲和系统。宁录可以操纵磁能悬浮钢铁，产生能量力场和瞬移。手臂和头部的探测器允许它定位和分析人类的能力，必要时修改自己的能力，于不同场合对抗和击败对手。在与X-Men的战斗中，宁录与母体模组接触并且融合为一，它被Siege Perilous送往其他世界，最终作为棱堡归来。
棱堡 (Bastion)
初登场于X-Men (Vol 2) #52。由宁录吸收巨大的机械哨兵母体模组而诞生。X-Men察觉到没有方法阻挡近乎坚不可摧的汞合金，除了使用Siege Perilous的力量强制送往其他维度，当他再次现身，已成为一名失忆、人类和哨兵混种的不朽存在，棱堡最初的指令很快地再次被唤醒，开始召集国际反变种人武装力量零容忍 (OZT) 行动。作为两个无比强大哨兵的结合，棱堡拥有众多能力，母体模组程式给予它完全掌控所有哨兵以及创造至尊哨兵的权力，有能力进入和控制任何电脑系统；宁录程式给予它高度的智慧，有能力评估变种人的威胁等级实施反制措施，它还能够从大多数的物理攻击下自我修复，免疫所有精神攻击。第二次弥赛亚降临时期，它计画除掉弥赛亚之子，下令杀死乌托邦内所有的传送能力者，以巨大的穹顶切断X-Men的逃生去路，然而它的计画被送往未来的X-Force小队阻止，棱堡打算亲手杀死Hope，但在失去Cable的愤怒之下，棱堡最终被她觉醒的力量给摧毁。
电影宇宙的版本：
哨兵Mark X
登场于电影X-Men: Days of Future Past (Earth-10005) 。1973年，魔形女在暗杀Bolivar Trask后被捕，Trask成为了哨兵计画实现的契机，一旦魔形女的血液被複製，新的哨兵很快在2013年首次公佈，并在2023年接管了世界。它们开始在世界各地狩猎变种人，将他们送往集中营处死或成为奴隶。最终它们开始狩猎可能传递变种基因的任何人类，造成大规模的叛乱，但叛乱很快被镇压，只留下最差劲的人类负责一切，残存的变种人开始为了生存而战。Mark X哨兵被设计成适应任何环境，允许它们模仿曾经遭遇过的变种能力，用以对抗变种人。它们可以改变身体外型，将手臂变化为刀刃、利爪、鑽头等形状。它们的头部能够像花瓣般展开，发射强大的高热能量束，足以烧毁和融化任何物体。最终，哨兵在中国一间寺院包围了残馀的变种人反抗军，Kitty将金钢狼的意识送回1973年，阻止魔形女的刺杀，因此导致哨兵支配的未来被删除。
一文带你了解Redis哨兵模式和高可用集群解析万字长文
前言
Redis 的 主从复制 模式下，一旦 主节点 由于故障不能提供服务，需要手动将 从节点 晋升为 主节点，同时还要通知 客户端 更新 主节点地址，这种故障处理方式从一定程度上是无法接受的。Redis 2.8 以后提供了 Redis sentinel 哨兵机制 来解决这个问题。
正文
1. Redis高可用概述
在 Web 服务器中，高可用 是指服务器可以 正常访问 的时间，衡量的标准是在 多长时间 内可以提供正常服务（99.9%、99.99%、99.999% 等等）。在 Redis 层面，高可用 的含义要宽泛一些，除了保证提供 正常服务（如 主从分离、快速容灾技术 等），还需要考虑 数据容量扩展、数据安全 等等。
在 Redis 中，实现 高可用 的技术主要包括 持久化、复制、哨兵 和 集群，下面简单说明它们的作用，以及解决了什么样的问题：
持久化：持久化是 最简单的 高可用方法。它的主要作用是 数据备份，即将数据存储在 硬盘，保证数据不会因进程退出而丢失。
复制：复制是高可用 Redis 的基础，哨兵 和 集群 都是在 复制基础 上实现高可用的。复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。
哨兵：在复制的基础上，哨兵实现了 自动化 的 故障恢复。缺陷是 写操作 无法 负载均衡，存储能力 受到 单机 的限制。
集群：通过集群，Redis 解决了 写操作 无法 负载均衡 以及 存储能力 受到 单机限制 的问题，实现了较为 完善 的 高可用方案。
2. Redis Sentinel的基本概念
Redis Sentinel 是 Redis 高可用 的实现方案。Sentinel 是一个管理多个 Redis 实例的工具，它可以实现对 Redis 的 监控、通知、自动故障转移。下面先对 Redis Sentinel 的 基本概念 进行简单的介绍。
基本名词说明：
如图所示，Redis 的 主从复制模式 和 Sentinel 高可用架构 的示意图：
3. Redis主从复制的问题
Redis 主从复制 可将 主节点 数据同步给 从节点，从节点此时有两个作用：
一旦 主节点宕机，从节点 作为 主节点 的 备份 可以随时顶上来。
扩展 主节点 的 读能力，分担主节点读压力。
主从复制 同时存在以下几个问题：
一旦 主节点宕机，从节点 晋升成 主节点，同时需要修改 应用方 的 主节点地址，还需要命令所有 从节点去 复制 新的主节点，整个过程需要 人工干预。
主节点 的 写能力 受到 单机的限制。
主节点 的 存储能力 受到 单机的限制。
原生复制 的弊端在早期的版本中也会比较突出，比如：Redis 复制中断 后，从节点 会发起 psync。此时如果 同步不成功，则会进行 全量同步，主库 执行 全量备份 的同时，可能会造成毫秒或秒级的 卡顿。
4. Redis Sentinel深入探究
4.1. Redis Sentinel的架构
4.2. Redis Sentinel的主要功能
Sentinel 的主要功能包括 主节点存活检测、主从运行情况检测、自动故障转移 （failover）、主从切换。Redis 的 Sentinel 最小配置是 一主一从。
Redis 的 Sentinel 系统可以用来管理多个 Redis 服务器，该系统可以执行以下四个任务：
监控
Sentinel 会不断的检查 主服务器 和 从服务器 是否正常运行。
通知
当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本 向 管理员 或者其他的 应用程序 发送通知。
自动故障转移
当 主节点 不能正常工作时，Sentinel 会开始一次 自动的 故障转移操作，它会将与 失效主节点 是 主从关系 的其中一个 从节点 升级为新的 主节点，并且将其他的 从节点 指向 新的主节点。
配置提供者
在 Redis Sentinel 模式下，客户端应用 在初始化时连接的是 Sentinel 节点集合，从中获取 主节点 的信息。
4.3. 主观下线和客观下线
默认情况下，每个 Sentinel 节点会以 每秒一次 的频率对 Redis 节点和 其它 的 Sentinel 节点发送 PING 命令，并通过节点的 回复 来判断节点是否在线。
主观下线
主观下线 适用于所有 主节点 和 从节点。如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到 目标节点 的有效回复，则会判定 该节点 为 主观下线。
客观下线
客观下线 只适用于 主节点。如果 主节点 出现故障，Sentinel 节点会通过 sentinel is-master-down-by-addr命令，向其它 Sentinel 节点询问对该节点的 状态判断。如果超过 <quorum> 个数的节点判定 主节点 不可达，则该 Sentinel 节点会判断 主节点 为 客观下线。
4.4. Sentinel的通信命令
Sentinel 节点连接一个 Redis 实例的时候，会创建 cmd 和 pub/sub 两个 连接。Sentinel 通过 cmd 连接给 Redis发送命令，通过 pub/sub 连接到 Redis 实例上的其他 Sentinel 实例。
Sentinel 与 Redis 主节点 和 从节点 交互的命令，主要包括：
Sentinel 与 Sentinel 交互的命令，主要包括：
4.5. Redis Sentinel的工作原理
每个 Sentinel 节点都需要 定期执行 以下任务：
每个 Sentinel 以 每秒钟 一次的频率，向它所知的 主服务器、从服务器 以及其他 Sentinel 实例 发送一个 PING 命令。
如果一个 实例（instance）距离 最后一次 有效回复 PING 命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel 标记为 主观下线。
如果一个 主服务器 被标记为 主观下线，那么正在 监视 这个 主服务器 的所有 Sentinel 节点，要以 每秒一次 的频率确认 主服务器 的确进入了 主观下线 状态。
如果一个 主服务器 被标记为 主观下线，并且有 足够数量 的 Sentinel（至少要达到 配置文件 指定的数量）在指定的 时间范围 内同意这一判断，那么这个 主服务器 被标记为 客观下线。
在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率，向它已知的所有 主服务器 和 从服务器 发送 INFO 命令。当一个 主服务器 被 Sentinel 标记为 客观下线 时，Sentinel 向 下线主服务器 的所有 从服务器 发送 INFO 命令的频率，会从 10 秒一次改为 每秒一次。
Sentinel 和其他 Sentinel 协商 主节点 的状态，如果 主节点 处于 SDOWN 状态，则投票自动选出新的 主节点。将剩余的 从节点 指向 新的主节点 进行 数据复制。
当没有足够数量的 Sentinel 同意 主服务器 下线时， 主服务器 的 客观下线状态 就会被移除。当 主服务器 重新向 Sentinel 的 PING 命令返回 有效回复 时，主服务器 的 主观下线状态 就会被移除。
注意：一个有效的 PING 回复可以是： PONG、-LOADING 或者 -MASTERDOWN。如果 服务器 返回除以上三种回复之外的其他回复，又或者在 指定时间 内没有回复 PING 命令， 那么 Sentinel 认为服务器返回的回复 无效（non-valid）。
5. Redis Sentinel搭建
5.1. Redis Sentinel的部署须知
一个稳健的 Redis Sentinel 集群，应该使用至少 三个 Sentinel 实例，并且保证讲这些实例放到 不同的机器 上，甚至不同的 物理区域。
Sentinel 无法保证 强一致性。
常见的 客户端应用库 都支持 Sentinel。
Sentinel 需要通过不断的 测试 和 观察，才能保证高可用。
5.2. Redis Sentinel的配置文件
# 哨兵sentinel实例运行的端口，默认26379 port 26379# 哨兵sentinel的工作目录dir ./# 哨兵sentinel监控的redis主节点的 ## ip：主机ip地址## port：哨兵端口号## master-name：可以自己命名的主节点名字（只能由字母A-z、数字0-9 、这三个字符".-_"组成。）## quorum：当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了 # sentinel monitor <master-name> <ip> <redis-port> <quorum> sentinel monitor mymaster 127.0.0.1 6379 2# 当在Redis实例中开启了requirepass <foobared>，所有连接Redis实例的客户端都要提供密码。# sentinel auth-pass <master-name> <password> sentinel auth-pass mymaster 123456 # 指定主节点应答哨兵sentinel的最大时间间隔，超过这个时间，哨兵主观上认为主节点下线，默认30秒 # sentinel down-after-milliseconds <master-name> <milliseconds>sentinel down-after-milliseconds mymaster 30000 # 指定了在发生failover主备切换时，最多可以有多少个slave同时对新的master进行同步。这个数字越小，完成failover所需的时间就越长；反之，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1，来保证每次只有一个slave，处于不能处理命令请求的状态。# sentinel parallel-syncs <master-name> <numslaves>sentinel parallel-syncs mymaster 1 # 故障转移的超时时间failover-timeout，默认三分钟，可以用在以下这些方面：## 1. 同一个sentinel对同一个master两次failover之间的间隔时间。 ## 2. 当一个slave从一个错误的master那里同步数据时开始，直到slave被纠正为从正确的master那里同步数据时结束。 ## 3. 当想要取消一个正在进行的failover时所需要的时间。## 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来同步数据了# sentinel failover-timeout <master-name> <milliseconds> sentinel failover-timeout mymaster 180000# 当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本。一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。# 对于脚本的运行结果有以下规则： ## 1. 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10。## 2. 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。 ## 3. 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。# sentinel notification-script <master-name> <script-path> sentinel notification-script mymaster /var/redis/notify.sh# 这个脚本应该是通用的，能被多次调用，不是针对性的。# sentinel client-reconfig-script <master-name> <script-path>sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
5.3. Redis Sentinel的节点规划
5.4. Redis Sentinel的配置搭建
5.4.1. Redis-Server的配置管理
分别拷贝三份 redis.conf 文件到 /usr/local/redis-sentinel 目录下面。三个配置文件分别对应 master、slave1 和 slave2 三个 Redis 节点的 启动配置。
$ sudo cp /usr/local/redis-4.0.11/redis.conf /usr/local/redis-sentinel/redis-16379.conf$ sudo cp /usr/local/redis-4.0.11/redis.conf /usr/local/redis-sentinel/redis-26379.conf$ sudo cp /usr/local/redis-4.0.11/redis.conf /usr/local/redis-sentinel/redis-36379.conf
分别修改三份配置文件如下：
主节点：redis-16379.conf
daemonize yespidfile /var/run/redis-16379.pidlogfile /var/log/redis/redis-16379.logport 16379bind 0.0.0.0timeout 300databases 16dbfilename dump-16379.dbdir ./redis-workdirmasterauth 123456requirepass 123456
从节点1：redis-26379.conf
daemonize yespidfile /var/run/redis-26379.pidlogfile /var/log/redis/redis-26379.logport 26379bind 0.0.0.0timeout 300databases 16dbfilename dump-26379.dbdir ./redis-workdirmasterauth 123456requirepass 123456slaveof 127.0.0.1 16379
从节点2：redis-36379.conf
daemonize yespidfile /var/run/redis-36379.pidlogfile /var/log/redis/redis-36379.logport 36379bind 0.0.0.0timeout 300databases 16dbfilename dump-36379.dbdir ./redis-workdirmasterauth 123456requirepass 123456slaveof 127.0.0.1 16379
如果要做 自动故障转移，建议所有的 redis.conf 都设置 masterauth。因为 自动故障 只会重写 主从关系，即 slaveof，不会自动写入 masterauth。如果 Redis 原本没有设置密码，则可以忽略。
5.4.2. Redis-Server启动验证
按顺序分别启动 16379，26379 和 36379 三个 Redis 节点，启动命令和启动日志如下：
Redis 的启动命令：
$ sudo redis-server /usr/local/redis-sentinel/redis-16379.conf$ sudo redis-server /usr/local/redis-sentinel/redis-26379.conf$ sudo redis-server /usr/local/redis-sentinel/redis-36379.conf
查看 Redis 的启动进程：
$ ps -ef | grep redis-server 0 7127 1 0 2:16下午 ?? 0:01.84 redis-server 0.0.0.0:16379 0 7133 1 0 2:16下午 ?? 0:01.73 redis-server 0.0.0.0:26379 0 7137 1 0 2:16下午 ?? 0:01.70 redis-server 0.0.0.0:36379
查看 Redis 的启动日志：
节点 redis-16379
$ cat /var/log/redis/redis-16379.log 7126:C 22 Aug 14:16:38.907 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo7126:C 22 Aug 14:16:38.908 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7126, just started7126:C 22 Aug 14:16:38.908 # Configuration loaded7127:M 22 Aug 14:16:38.910 * Increased maximum number of open files to 10032 (it was originally set to 256).7127:M 22 Aug 14:16:38.912 * Running mode=standalone, port=16379.7127:M 22 Aug 14:16:38.913 # Server initialized7127:M 22 Aug 14:16:38.913 * Ready to accept connections7127:M 22 Aug 14:16:48.416 * Slave 127.0.0.1:26379 asks for synchronization7127:M 22 Aug 14:16:48.416 * Full resync requested by slave 127.0.0.1:263797127:M 22 Aug 14:16:48.416 * Starting BGSAVE for SYNC with target: disk7127:M 22 Aug 14:16:48.416 * Background saving started by pid 71347134:C 22 Aug 14:16:48.433 * DB saved on disk7127:M 22 Aug 14:16:48.487 * Background saving terminated with success7127:M 22 Aug 14:16:48.494 * Synchronization with slave 127.0.0.1:26379 succeeded7127:M 22 Aug 14:16:51.848 * Slave 127.0.0.1:36379 asks for synchronization7127:M 22 Aug 14:16:51.849 * Full resync requested by slave 127.0.0.1:363797127:M 22 Aug 14:16:51.849 * Starting BGSAVE for SYNC with target: disk7127:M 22 Aug 14:16:51.850 * Background saving started by pid 71387138:C 22 Aug 14:16:51.862 * DB saved on disk7127:M 22 Aug 14:16:51.919 * Background saving terminated with success7127:M 22 Aug 14:16:51.923 * Synchronization with slave 127.0.0.1:36379 succeeded
以下两行日志日志表明，redis-16379 作为 Redis 的 主节点，redis-26379 和 redis-36379 作为 从节点，从 主节点 同步数据。
7127:M 22 Aug 14:16:48.416 * Slave 127.0.0.1:26379 asks for synchronization7127:M 22 Aug 14:16:51.848 * Slave 127.0.0.1:36379 asks for synchronization
节点 redis-26379
$ cat /var/log/redis/redis-26379.log 7132:C 22 Aug 14:16:48.407 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo7132:C 22 Aug 14:16:48.408 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7132, just started7132:C 22 Aug 14:16:48.408 # Configuration loaded7133:S 22 Aug 14:16:48.410 * Increased maximum number of open files to 10032 (it was originally set to 256).7133:S 22 Aug 14:16:48.412 * Running mode=standalone, port=26379.7133:S 22 Aug 14:16:48.413 # Server initialized7133:S 22 Aug 14:16:48.413 * Ready to accept connections7133:S 22 Aug 14:16:48.413 * Connecting to MASTER 127.0.0.1:163797133:S 22 Aug 14:16:48.413 * MASTER <-> SLAVE sync started7133:S 22 Aug 14:16:48.414 * Non blocking connect for SYNC fired the event.7133:S 22 Aug 14:16:48.414 * Master replied to PING, replication can continue...7133:S 22 Aug 14:16:48.415 * Partial resynchronization not possible (no cached master)7133:S 22 Aug 14:16:48.417 * Full resync from master: 211d3b4eceaa3af4fe5c77d22adf06e1218e0e7b:07133:S 22 Aug 14:16:48.494 * MASTER <-> SLAVE sync: receiving 176 bytes from master7133:S 22 Aug 14:16:48.495 * MASTER <-> SLAVE sync: Flushing old data7133:S 22 Aug 14:16:48.496 * MASTER <-> SLAVE sync: Loading DB in memory7133:S 22 Aug 14:16:48.498 * MASTER <-> SLAVE sync: Finished with success
节点 redis-36379
$ cat /var/log/redis/redis-36379.log 7136:C 22 Aug 14:16:51.839 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo7136:C 22 Aug 14:16:51.840 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7136, just started7136:C 22 Aug 14:16:51.841 # Configuration loaded7137:S 22 Aug 14:16:51.843 * Increased maximum number of open files to 10032 (it was originally set to 256).7137:S 22 Aug 14:16:51.845 * Running mode=standalone, port=36379.7137:S 22 Aug 14:16:51.845 # Server initialized7137:S 22 Aug 14:16:51.846 * Ready to accept connections7137:S 22 Aug 14:16:51.846 * Connecting to MASTER 127.0.0.1:163797137:S 22 Aug 14:16:51.847 * MASTER <-> SLAVE sync started7137:S 22 Aug 14:16:51.847 * Non blocking connect for SYNC fired the event.7137:S 22 Aug 14:16:51.847 * Master replied to PING, replication can continue...7137:S 22 Aug 14:16:51.848 * Partial resynchronization not possible (no cached master)7137:S 22 Aug 14:16:51.850 * Full resync from master: 211d3b4eceaa3af4fe5c77d22adf06e1218e0e7b:147137:S 22 Aug 14:16:51.923 * MASTER <-> SLAVE sync: receiving 176 bytes from master7137:S 22 Aug 14:16:51.923 * MASTER <-> SLAVE sync: Flushing old data7137:S 22 Aug 14:16:51.924 * MASTER <-> SLAVE sync: Loading DB in memory7137:S 22 Aug 14:16:51.927 * MASTER <-> SLAVE sync: Finished with success
5.4.3. Sentinel的配置管理
分别拷贝三份 redis-sentinel.conf 文件到 /usr/local/redis-sentinel 目录下面。三个配置文件分别对应 master、slave1 和 slave2 三个 Redis 节点的 哨兵配置。
$ sudo cp /usr/local/redis-4.0.11/sentinel.conf /usr/local/redis-sentinel/sentinel-16380.conf$ sudo cp /usr/local/redis-4.0.11/sentinel.conf /usr/local/redis-sentinel/sentinel-26380.conf$ sudo cp /usr/local/redis-4.0.11/sentinel.conf /usr/local/redis-sentinel/sentinel-36380.conf
节点1：sentinel-16380.conf
protected-mode nobind 0.0.0.0port 16380daemonize yessentinel monitor master 127.0.0.1 16379 2sentinel down-after-milliseconds master 5000sentinel failover-timeout master 180000sentinel parallel-syncs master 1sentinel auth-pass master 123456logfile /var/log/redis/sentinel-16380.log
节点2：sentinel-26380.conf
protected-mode nobind 0.0.0.0port 26380daemonize yessentinel monitor master 127.0.0.1 16379 2sentinel down-after-milliseconds master 5000sentinel failover-timeout master 180000sentinel parallel-syncs master 1sentinel auth-pass master 123456logfile /var/log/redis/sentinel-26380.log
节点3：sentinel-36380.conf
protected-mode nobind 0.0.0.0port 36380daemonize yessentinel monitor master 127.0.0.1 16379 2sentinel down-after-milliseconds master 5000sentinel failover-timeout master 180000sentinel parallel-syncs master 1sentinel auth-pass master 123456logfile /var/log/redis/sentinel-36380.log
5.4.4. Sentinel启动验证
按顺序分别启动 16380，26380 和 36380 三个 Sentinel 节点，启动命令和启动日志如下：
$ sudo redis-sentinel /usr/local/redis-sentinel/sentinel-16380.conf$ sudo redis-sentinel /usr/local/redis-sentinel/sentinel-26380.conf$ sudo redis-sentinel /usr/local/redis-sentinel/sentinel-36380.conf
查看 Sentinel 的启动进程：
$ ps -ef | grep redis-sentinel 0 7954 1 0 3:30下午 ?? 0:00.05 redis-sentinel 0.0.0.0:16380 [sentinel] 0 7957 1 0 3:30下午 ?? 0:00.05 redis-sentinel 0.0.0.0:26380 [sentinel] 0 7960 1 0 3:30下午 ?? 0:00.04 redis-sentinel 0.0.0.0:36380 [sentinel]
查看 Sentinel 的启动日志：
节点 sentinel-16380
$ cat /var/log/redis/sentinel-16380.log 7953:X 22 Aug 15:30:27.245 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo7953:X 22 Aug 15:30:27.245 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7953, just started7953:X 22 Aug 15:30:27.245 # Configuration loaded7954:X 22 Aug 15:30:27.247 * Increased maximum number of open files to 10032 (it was originally set to 256).7954:X 22 Aug 15:30:27.249 * Running mode=sentinel, port=16380.7954:X 22 Aug 15:30:27.250 # Sentinel ID is 69d05b86a82102a8919231fd3c2d1f21ce86e0007954:X 22 Aug 15:30:27.250 # monitor master master 127.0.0.1 16379 quorum 27954:X 22 Aug 15:30:32.286 # sdown sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 163797954:X 22 Aug 15:30:34.588 # -sdown sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379
sentinel-16380 节点的 Sentinel ID 为 69d05b86a82102a8919231fd3c2d1f21ce86e000，并通过 Sentinel ID 把自身加入 sentinel 集群中。
节点 sentinel-26380
$ cat /var/log/redis/sentinel-26380.log 7956:X 22 Aug 15:30:30.900 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo7956:X 22 Aug 15:30:30.901 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7956, just started7956:X 22 Aug 15:30:30.901 # Configuration loaded7957:X 22 Aug 15:30:30.904 * Increased maximum number of open files to 10032 (it was originally set to 256).7957:X 22 Aug 15:30:30.905 * Running mode=sentinel, port=26380.7957:X 22 Aug 15:30:30.906 # Sentinel ID is 21e30244cda6a3d3f55200bcd904d0877574e5067957:X 22 Aug 15:30:30.906 # monitor master master 127.0.0.1 16379 quorum 27957:X 22 Aug 15:30:30.907 * slave slave 127.0.0.1:26379 127.0.0.1 26379 @ master 127.0.0.1 163797957:X 22 Aug 15:30:30.911 * slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 163797957:X 22 Aug 15:30:36.311 * sentinel sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379
sentinel-26380 节点的 Sentinel ID 为 21e30244cda6a3d3f55200bcd904d0877574e506，并通过 Sentinel ID 把自身加入 sentinel 集群中。此时 sentinel 集群中已有 sentinel-16380 和 sentinel-26380 两个节点。
节点 sentinel-36380
$ cat /var/log/redis/sentinel-36380.log 7959:X 22 Aug 15:30:34.273 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo7959:X 22 Aug 15:30:34.274 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7959, just started7959:X 22 Aug 15:30:34.274 # Configuration loaded7960:X 22 Aug 15:30:34.276 * Increased maximum number of open files to 10032 (it was originally set to 256).7960:X 22 Aug 15:30:34.277 * Running mode=sentinel, port=36380.7960:X 22 Aug 15:30:34.278 # Sentinel ID is fd166dc66425dc1d9e2670e1f17cb94fe05f5fc77960:X 22 Aug 15:30:34.278 # monitor master master 127.0.0.1 16379 quorum 27960:X 22 Aug 15:30:34.279 * slave slave 127.0.0.1:26379 127.0.0.1 26379 @ master 127.0.0.1 163797960:X 22 Aug 15:30:34.283 * slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 163797960:X 22 Aug 15:30:34.993 * sentinel sentinel 21e30244cda6a3d3f55200bcd904d0877574e506 127.0.0.1 26380 @ master 127.0.0.1 16379
sentinel-36380 节点的 Sentinel ID 为 fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7，并通过 Sentinel ID 把自身加入 sentinel 集群中。此时 sentinel 集群中已有 sentinel-16380，sentinel-26380 和 sentinel-36380 三个节点。
5.4.5. Sentinel配置刷新
节点1：sentinel-16380.conf
sentinel-16380.conf 文件新生成如下的配置项：
# Generated by CONFIG REWRITEdir "/usr/local/redis-sentinel"sentinel config-epoch master 0sentinel leader-epoch master 0sentinel known-slave master 127.0.0.1 36379sentinel known-slave master 127.0.0.1 26379sentinel known-sentinel master 127.0.0.1 26380 21e30244cda6a3d3f55200bcd904d0877574e506sentinel known-sentinel master 127.0.0.1 36380 fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7sentinel current-epoch 0
可以注意到，sentinel-16380.conf 刷新写入了 Redis 主节点关联的所有 从节点 redis-26379 和 redis-36379，同时写入了其余两个 Sentinel 节点 sentinel-26380 和 sentinel-36380 的 IP 地址，端口号 和 Sentinel ID。
# Generated by CONFIG REWRITEdir "/usr/local/redis-sentinel"sentinel config-epoch master 0sentinel leader-epoch master 0sentinel known-slave master 127.0.0.1 26379sentinel known-slave master 127.0.0.1 36379sentinel known-sentinel master 127.0.0.1 36380 fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7sentinel known-sentinel master 127.0.0.1 16380 69d05b86a82102a8919231fd3c2d1f21ce86e000sentinel current-epoch 0
可以注意到，sentinel-26380.conf 刷新写入了 Redis 主节点关联的所有 从节点 redis-26379 和 redis-36379，同时写入了其余两个 Sentinel 节点 sentinel-36380 和 sentinel-16380 的 IP 地址，端口号 和 Sentinel ID。
# Generated by CONFIG REWRITEdir "/usr/local/redis-sentinel"sentinel config-epoch master 0sentinel leader-epoch master 0sentinel known-slave master 127.0.0.1 36379sentinel known-slave master 127.0.0.1 26379sentinel known-sentinel master 127.0.0.1 16380 69d05b86a82102a8919231fd3c2d1f21ce86e000sentinel known-sentinel master 127.0.0.1 26380 21e30244cda6a3d3f55200bcd904d0877574e506sentinel current-epoch 0
可以注意到，sentinel-36380.conf 刷新写入了 Redis 主节点关联的所有 从节点 redis-26379 和 redis-36379，同时写入了其余两个 Sentinel 节点 sentinel-16380 和 sentinel-26380 的 IP 地址，端口号 和 Sentinel ID。
5.5. Sentinel时客户端命令
检查其他 Sentinel 节点的状态，返回 PONG 为正常。
> PING sentinel
显示被监控的所有 主节点 以及它们的状态。
> SENTINEL masters
显示指定 主节点 的信息和状态。
> SENTINEL master <master_name>
显示指定 主节点 的所有 从节点 以及它们的状态。
> SENTINEL slaves <master_name>
返回指定 主节点 的 IP 地址和 端口。如果正在进行 failover 或者 failover 已经完成，将会显示被提升为 主节点 的 从节点 的 IP 地址和 端口。
> SENTINEL get-master-addr-by-name <master_name>
重置名字匹配该 正则表达式 的所有的 主节点 的状态信息，清除它之前的 状态信息，以及 从节点 的信息。
> SENTINEL reset <pattern>
强制当前 Sentinel 节点执行 failover，并且不需要得到其他 Sentinel 节点的同意。但是 failover 后会将 最新的配置 发送给其他 Sentinel 节点。
>SENTINEL failover <master_name>
6. Redis Sentinel故障切换与恢复
6.1. Redis CLI客户端跟踪
上面的日志显示，redis-16379 节点为 主节点，它的进程 ID 为 7127。为了模拟 Redis 主节点故障，强制杀掉这个进程。
$ kill -9 7127
使用 redis-cli 客户端命令进入 sentinel-16380 节点，查看 Redis 节点 的状态信息。
$ redis-cli -p 16380
查看 Redis 主从集群的 主节点 信息。可以发现 redis-26379 晋升为 新的主节点。
127.0.0.1:16380> SENTINEL master master 1) "name" 2) "master" 3) "ip" 4) "127.0.0.1" 5) "port" 6) "26379" 7) "runid" 8) "b8ca3b468a95d1be5efe1f50c50636cafe48c59f" 9) "flags"10) "master"11) "link-pending-commands"12) "0"13) "link-refcount"14) "1"15) "last-ping-sent"16) "0"17) "last-ok-ping-reply"18) "588"19) "last-ping-reply"20) "588"21) "down-after-milliseconds"22) "5000"23) "info-refresh"24) "9913"25) "role-reported"26) "master"27) "role-reported-time"28) "663171"29) "config-epoch"30) "1"31) "num-slaves"32) "2"33) "num-other-sentinels"34) "2"35) "quorum"36) "2"37) "failover-timeout"38) "180000"39) "parallel-syncs"40) "1"
6.2. Redis Sentinel日志跟踪
查看任意 Sentinel 节点的日志如下：
7954:X 22 Aug 18:40:22.504 # tilt #tilt mode entered7954:X 22 Aug 18:40:32.197 # tilt #tilt mode entered7954:X 22 Aug 18:41:02.241 # -tilt #tilt mode exited7954:X 22 Aug 18:48:24.550 # sdown master master 127.0.0.1 163797954:X 22 Aug 18:48:24.647 # new-epoch 17954:X 22 Aug 18:48:24.651 # vote-for-leader fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 17954:X 22 Aug 18:48:25.678 # odown master master 127.0.0.1 16379 #quorum 3/27954:X 22 Aug 18:48:25.678 # Next failover delay: I will not start a failover before Wed Aug 22 18:54:24 20187954:X 22 Aug 18:48:25.709 # config-update-from sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 163797954:X 22 Aug 18:48:25.710 # switch-master master 127.0.0.1 16379 127.0.0.1 263797954:X 22 Aug 18:48:25.710 * slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 263797954:X 22 Aug 18:48:25.711 * slave slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 263797954:X 22 Aug 18:48:30.738 # sdown slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 263797954:X 22 Aug 19:38:23.479 # -sdown slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379
分析日志，可以发现 redis-16329 节点先进入 sdown 主观下线 状态。
sdown master master 127.0.0.1 16379
哨兵检测到 redis-16329 出现故障，Sentinel 进入一个 新纪元，从 0 变为 1。
new-epoch 1
三个 Sentinel 节点开始协商 主节点 的状态，判断其是否需要 客观下线。
vote-for-leader fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 1
超过 quorum 个数的 Sentinel 节点认为 主节点 出现故障，redis-16329 节点进入 客观下线 状态。
odown master master 127.0.0.1 16379 #quorum 3/2
Sentinal 进行 自动故障切换，协商选定 redis-26329 节点作为新的 主节点。
switch-master master 127.0.0.1 16379 127.0.0.1 26379
redis-36329 节点和已经 客观下线 的 redis-16329 节点成为 redis-26479 的 从节点。
7954:X 22 Aug 18:48:25.710 * slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 263797954:X 22 Aug 18:48:25.711 * slave slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379
6.3. Redis的配置文件
分别查看三个 redis 节点的配置文件，发生 主从切换 时 redis.conf 的配置会自动发生刷新。
节点 redis-16379
daemonize yespidfile "/var/run/redis-16379.pid"logfile "/var/log/redis/redis-16379.log"port 16379bind 0.0.0.0timeout 300databases 16dbfilename "dump-16379.db"dir "/usr/local/redis-sentinel/redis-workdir"masterauth "123456"requirepass "123456"
节点 redis-26379
daemonize yespidfile "/var/run/redis-26379.pid"logfile "/var/log/redis/redis-26379.log"port 26379bind 0.0.0.0timeout 300databases 16dbfilename "dump-26379.db"dir "/usr/local/redis-sentinel/redis-workdir"masterauth "123456"requirepass "123456"
节点 redis-36379
daemonize yespidfile "/var/run/redis-36379.pid"logfile "/var/log/redis/redis-36379.log"port 36379bind 0.0.0.0timeout 300databases 16dbfilename "dump-36379.db"dir "/usr/local/redis-sentinel/redis-workdir"masterauth "123456"requirepass "123456"slaveof 127.0.0.1 26379
分析：redis-26379 节点 slaveof 配置被移除，晋升为 主节点。redis-16379 节点处于 宕机状态。redis-36379 的 slaveof 配置更新为 127.0.0.1 redis-26379，成为 redis-26379 的 从节点。
重启节点 redis-16379。待正常启动后，再次查看它的 redis.conf 文件，配置如下：
daemonize yespidfile "/var/run/redis-16379.pid"logfile "/var/log/redis/redis-16379.log"port 16379bind 0.0.0.0timeout 300databases 16dbfilename "dump-16379.db"dir "/usr/local/redis-sentinel/redis-workdir"masterauth "123456"requirepass "123456"# Generated by CONFIG REWRITEslaveof 127.0.0.1 26379
节点 redis-16379 的配置文件新增一行 slaveof 配置属性，指向 redis-26379，即成为 新的主节点 的 从节点。
小结
本文首先对 Redis 实现高可用的几种模式做出了阐述，指出了 Redis 主从复制 的不足之处，进一步引入了 Redis Sentinel 哨兵模式 的相关概念，深入说明了 Redis Sentinel 的 具体功能，基本原理，高可用搭建 和 自动故障切换 验证等。
当然，Redis Sentinel 仅仅解决了 高可用 的问题，对于 主节点 单点写入和单节点无法扩容等问题，还需要引入 Redis Cluster 集群模式 予以解决。