高可用

redis 高可用 主从复制 ###redis 高可用 主从复制 ###所有节点运行 wget http://download.redis.io/releases/redis-3.2.12.tar.gz yum install -y gcc tar xzf redis-3.2.12.tar.gz -C /usr/src/ cd /usr/src/redis-3.2.12 make && make install PREFIX=/usr/local/redis \cp src/redis-trib.rb /usr/local/redis/bin/ \cp -f utils/redis_init_script /etc/init.d/redis sed -i '/stop)/ i #\n\trestart)\n\t\t$0 stop\n\t\t$0 start\n\t;;' /etc/init.d/redis mkdir /usr/local/redis/conf ln -s /usr/local/redis/conf /etc/redis ln -s /usr/local/redis/bin/redis-trib.rb /usr/local/bin/redis-trib.rb grep -Ev '^#|^$' redis.conf >/etc/redis/6379.conf sed

在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用 mysql 主 主 方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加 mysql 入口，增加高可用。 不过多主需要考虑自增长 ID 问题，这个需要特别设置配置文件，比如双主，可以使用奇偶 ， 总之，主之间设置自增长 ID 相互不冲突就能完美解决自增长 ID 冲突问题 主主方案实现思路 1、 两台 mysql 都可读写，互为主备 。 默认只使用一台 masterA 负责数据的写入，另一台 masterB 备用 处于备用状态 ； 2、 masterA 是 masterB 的主库， masterB 又是 masterA 的主库，它们互为主从； 3、 两台主库之间做高可用 , 可以采用 keepalived 等方案 ， 使用 VIP 对外提供服务； 4 、 所有提供服务的从服务器与 masterB 进行主从同步（双主多从） ; 5 、 建议采用高可用策略的时候， masterA 或 masterB 均不因宕机恢复后而抢占 VIP （非抢占模式）； 这样做可以在一定程度上保证主库的高可用 , 在一台主库 down 掉之后 , 可以在极短的时间内切换到另一台主库上 ， 尽可能减少主库宕机对业务造成的影响，减少了主从同步给 生产 主库带来的压力； 实验步骤：

MySQL 主主同步方案 l MySQL 主主 +Keepalived l MySQL+DRBD+Heartbeat 在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用 mysql 主主方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加 mysql 入口，增加高可用。 不过多主需要考虑自增长 ID 问题，这个需要特别设置配置文件，比如双主，可以使用奇偶 ，总之，主之间设置自增长 ID 相互不冲突就能完美解决自增长 ID 冲突问题。 主主方案实现思路 1、 两台 mysql 都可读写，互为主备。默认只使用一台 masterA 负责数据的写入，另一台 masterB 备用处于备用状态； 2、 masterA 是 masterB 的主库， masterB 又是 masterA 的主库，它们互为主从； 3、 两台主库之间做高可用 , 可以采用 keepalived 等方案，使用 VIP 对外提供服务； 4 、所有提供服务的从服务器与 masterB 进行主从同步（双主多从） ; 5 、建议采用高可用策略的时候， masterA 或 masterB 均不因宕机恢复后而抢占 VIP （非抢占模式）； 这样做可以在一定程度上保证主库的高可用 , 在一台主库 down 掉之后 , 可以在极短的时间内切换到另一台主库上

前几天拜读了 OpsGenie 公司（一家致力于 Dev & Ops 的公司）的资深工程师 Turgay Çelik 博士写的一篇文章（链接在文末），文中介绍了他们最初也是采用 Nginx 作为单体应用的网关，后来接触到微服务架构后开始逐渐采用了其他组件。 我对于所做的工作或者感兴趣的技术，喜欢刨根问底，所以当读一篇文章时发现没有看到我想要看到的设计思想，我就会四处搜集资料，此外这篇文章涉及了我正在捣鼓的 Spring Cloud，所以我就决定写一篇文章，争取能从设计思路上解释为什么会有这样的性能差异。 技术介绍 文中针对 Nginx、ZUUL、Spring Cloud、Linkerd 等技术进行了对比（其实还有 Envoy 和 UnderTow 也是属于可选的 API 网关，本文不予涉及），那我就分别进行介绍，当然，首先得介绍 API 网关。 API 网关 API 网关出现的原因是微服务架构的出现，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会有以下的问题： 客户端会多次请求不同的微服务，增加了客户端的复杂性。 存在跨域请求，在一定场景下处理相对复杂。 认证复杂，每个服务都需要独立认证。 难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个

《叶问》是知数堂新设计的互动栏目，不定期给大家提供技术知识小贴士，形式不限，或提问、或讨论均可，并在当天发布答案，让大家轻轻松松利用碎片时间就可以学到最实用的知识点。 2019年09月03日，周二 如何将excel数据导入MySQL表中？ 将excel导入MySQL表的方式有很多，这里列举几种平时常用的方法： 1、将excel另存为csv文件，再使用LOAD DATA导入表，命令参考如下： LOAD DATA INFILE 'c:/tmp/discounts.csv' INTO TABLE discounts FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 ROWS; 2、利用Navicat、MySQL Workbench等第三方工具进行导入 3、excel利用函数拼接成insert SQL进行数据插入(数据量大时不推荐，效率极低) 4、例行批量导入，安利python的xlwt模块 注意：进行数据导入时注意先执行set names设置字符集，以免造成乱码 2019年09月05日，周四 用xtrabackup跑mysql物理备份，建议授予哪些权限？ 可能需要用到以下权限： 1、RELOAD and LOCK TABLES (用于FLUSH TABLES WITH READ LOCK

降级。 　　 对于一个高可用服务，很重要的一个设计就是降级开关。在设计降级开关时，主要有以下思路： 　　　　1.开关集中化管理：通过推送机制把开关推送到各个应用。 　　　　2.可降级的多级服务：比如服务调用降级为只读本地缓存，只读分布式缓存，只读默认降级数据（如库存状态默认有货） 　　　　3.开关前置化：如架构是nginx --> tomcat，可以将开关前置到nginx接入层，在nginx层做开关，请求流量不回源后端tomcat应用或者只是一小部分流量回源。 　　　　4.业务降级：当高并发流量来袭，在电商系统大促设计时保障用户能下单，能支付是核心要求，并保障数据最终一致性即可。这样就可以把一些同步调用改为异步调用，优先处理高优先级数据或特殊特征的数据，合理分配进入系统的流量，以保证系统可用。 限流　　 　　 限流的目的是防止恶意请求流量、恶意攻击，或者防止流量超出系统峰值。可以考虑以下思路： 　　　　1.恶意请求流量只访问到cache。 　　　　2.对于穿透到后端应用的流量可以考虑使用nginx的limit模块处理。pinb 　　　　3.对于恶意IP可以使用nginx deny进行屏蔽。 　　这些操作的原则是限制流量穿透到后端薄弱的应用层。 可回滚 　　 版本化的目的是实现可审计可追溯，并且可回滚。当程序或者数据出错时，如果有版本化机制，那么就可以通过回滚恢复到最近一个正确的版本

美团外卖从2013年9月成交第一单以来，已走过了三个年头。期间，业务飞速发展，美团外卖由日均几单发展为日均500万单（9月11日已突破600万）的大型O2O互联网外卖服务平台。平台支持的品类也由最初外卖单品拓展为全品类。 随着订单量的增长、业务复杂度的提升，外卖订单系统也在不断演变进化，从早期一个订单业务模块到现在分布式可扩展的高性能、高可用、高稳定订单系统。整个发展过程中，订单系统经历了几个明显的阶段，下面本篇文章将为大家介绍一下订单系统的演进过程，重点关注各阶段的业务特征、挑战及应对之道。 为方便大家更好地了解整个演进过程，我们首先看一下外卖业务。 外卖订单业务 外卖订单业务是一个需要即时送的业务，对实时性要求很高。从用户订餐到最终送达用户，一般在1小时内。如果最终送达用户时间变长，会带来槽糕的用户体验。在1小时内，订单会快速经过多个阶段，直到最终送达用户。各个阶段需要紧密配合，确保订单顺利完成。 下图是一个用户视角的订单流程图： 从普通用户的角度来看，一个外卖订单从下单后，会经历支付、商家接单、配送、用户收货、售后及订单完成多个阶段。以技术的视角来分解的话，每个阶段依赖于多个子服务来共同完成，比如下单会依赖于购物车、订单预览、确认订单服务，这些子服务又会依赖于底层基础系统来完成其功能。 外卖业务另一个重要特征是一天内订单量会规律变化，订单会集中在中午、晚上两个“饭点”附近

1 高可用安装 1.1 集群信息 主机 IP 组件 bdc212 192.168.13.212 LVS:ipvsadm-1.27-7.el7.x86_64.rpm Keepalived: keepalived-1.2.4.tar.gz 应用：Percona-XtraDB-Cluster bdc213 192.168.13.213 LVS:ipvsadm-1.27-7.el7.x86_64.rpm Keepalived: keepalived-1.2.4.tar.gz 应用：Percona-XtraDB-Cluster bdc214 192.168.13.214 应用：Percona-XtraDB-Cluster 1.2 安装准备 上传安装所需的压缩包到/opt目录 keepalived-1.2.4.tar.gz ( http://www.keepalived.org/software/keepalived-1.2.4.tar.gz ) 安装组件所需依赖包 yum install openssl-devel popt-devel libnl* -y 1.3 安装LVS+keepalived 在两台Director Server上分别安装LVS+Keepalived，BACKUP服务器与MASTER服务器一致，先安装lvs再安装keepalived。 1.3.3 安装LVS Ipvs

本文链接：https://blog.csdn.net/m0_38125278/article/details/95046242 分布式架构的架构稳定性 接上一期架构性能，本期讲架构稳定性 1.服务拆分 服务拆分主要有两个目的：一是为了隔离故障，二是为了重用服务模块。但服务拆分完之后，会引入服务调用间的依赖问题。 2.服务冗余 服务冗余是为了去除单点故障，并可以支持服务的弹性伸缩，以及故障迁移。然而，对于一些有状态的服务来说，冗余这些有状态的服务带来了更高的复杂性。其中一个是弹性伸缩时，需要考虑数据的复制或是重新分片，迁移的时候还要迁移数据到其它机器上。 3.限流降级 当系统实在扛不住压力时，只能通过限流或者功能降级的方式来停掉一部分服务，或是拒绝一部分用户，以确保整个架构不会挂掉。这些技术属于保护措施。 4.高可用架构 通常来说高可用架构是从冗余架构的角度来保障可用性。比如，多租户隔离，灾备多活，或是数据可以在其中复制保持一致性的集群。总之，就是为了不出单点故障。 4.高可用运维 高可用运维指的是 DevOps 中的 CI/CD（持续集成 / 持续部署）。一个良好的运维应该是一条很流畅的软件发布管线，其中做了足够的自动化测试，还可以做相应的灰度发布，以及对线上系统的自动化控制。这样，可以做到“计划内”或是“非计划内”的宕机事件的时长最短。 上述这些技术非常有技术含量

目录 一、简介 二、基本模型 BSON 数据类型 分布式ID 三、操作语法 四、索引 索引特性 索引分类 索引评估、调优 五、集群 分片机制 副本集 六、事务与一致性 一致性 小结 一、简介 MongoDB 是一款流行的开源文档型数据库，从它的命名来看，确实是有一定野心的。 MongoDB 的原名一开始 来自于 英文单词"Humongous", 中文含义是指"庞大" ，即命名者的意图是可以处理大规模的数据。 但笔者更喜欢称呼它为 "芒果"数据库，除了译音更加相近之外，原因还来自于这几年使用 MongoDB 的两层感觉： 第一层感受是"爽"，使用这个文档数据库的特点是几乎不受什么限制，一方面Json文档式的结构更容易理解，而无Schema约束也让DDL管理更加简单，一切都可以很快速的进行。 第二层感受是"酸爽"，这点相信干运维或是支撑性工作的兄弟感受会比较深刻，MongoDB 由于入门体验"太过于友好"，导致一些团队认为用好这个数据库是个很简单的事情，所以开发兄弟在存量系统上埋一些坑也是正常的事情。 所谓交付一时爽，维护火葬场.. 当然了，这句话可能有些过。 但这里的潜台词是：与传统的RDBMS数据库一样，MongoDB 在使用上也需要认真的考量和看护，不然的化，会遇到更多的坑。 那么，尽管文档数据库在选型上会让一些团队望而却步，仍然不阻碍该数据库所获得的一些支持，比如 DB