高可用

3 月，跳不动了？>>> 前言：在前面讲到了Redis分片机制可实现内存数据的扩容来提高执行速率--- Redis分片机制 ，可是Redis分片依旧有一些问题，如果redis分片的节点如果有一个服务器宕机,则直接影响用户的使用.Redis分片机制没有实现高可用功能(HA)。----我所使用的Linux系统是dsCentOS-empty 1.Redis高可用哨兵机制 1.1主从同步配置 1.1.1 主从同步说明 说明:如果需要实现redis的高可用(HA),则必须先实现主从的同步。 当用户操作主节点时,由程序内部自动的实现数据的同步,将数据同步给从节点.这时主机和从机拥有相同的数据。 1.1.2 准备哨兵的Redis节点 说明: 1.首先将redis的分片服务器全部关闭。 2.复制分片的文件目录,并且改名为sentinel cp -r shards sentinel 3.删除多余的持久化文件 rm -f dump.rdb 4.分别启动redis redis-server 6379.conf & redis-server 6380.conf & redis-server 6381.conf & 检查Redis启动是否正常. 1.1.3检查Redis节点状态 命令: 要求在redis的客户端中执行 info replication role:master 说明是主机， connevted

1 高可用 什么是高可用：（High Availability） 在一个长时间内服务不受影响。通俗的讲就是，一个机器挂掉的时候，有其他机器可以继续提供同样的服务。 如何实现高可用： 冗余+自动故障转移。冗余即提供备份服务器，自动故障转移即当一个服务挂掉的时候，检测机制可以检查到，会实施自动的故障转移。 分层系统架构如何实现高可用： （1）【客户端层】到【反向代理层】的高可用，是通过反向代理层的冗余实现的，常见实践是keepalived + virtual IP自动故障转移； （2）【反向代理层】到【站点层】的高可用，是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与自动故障转移； （3）【站点层】到【服务层】的高可用，是通过服务层的冗余实现的，常见实践是通过service-connection-pool来保证自动故障转移； （4）【服务层】到【缓存层】的高可用，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性； （5）【服务层】到【数据库“读”】的高可用，是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证自动故障转移； （6）【服务层】到【数据库“写”】的高可用

ZooKeeper 是 Apache 的一个顶级项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基 础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性，被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。 　　 本文的目标读者是对 ZooKeeper 有一定了解的技术人员，将从 ZooKeeper 运行模式、集群组成、容灾和水平扩容四方面逐步深入，最终构建出高可用的 ZooKeeper 集群。 运行模式 　　Zookeeper 有三种运行模式：单机模式、伪集群模式和集群模式。 单机模式 　　这种模式一般适用于开发测试环境，一方面我们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。 　　在 Linux 环境下运行单机模式需要执行以下步骤： 　　 1. 准备 Java 运行环境 　　　　安装 Java 1.6 或更高版本的 JDK，并配置好 Java 相关的环境变量 $JAVA_HOME 。 　　 2. 下载 ZooKeeper 安装包 　　　　下载地址： http://zookeeper.apache.org/releases.html 。选择最新的 stable 版本并解压到指定目录，我们用 $ZK_HOME

本文来自 网易云社区 作者：李弈远 消息推送平台为公司内部和第三方应用提供统一消息推送服务，支持广播、私信、组播、附件等多种消息推送方式，覆盖IOS、Android、PC、Web等多种终端，并根据应用特定需求制定各种解决方案。 平台支持水平扩展，支持C5000K高并发下的实时消息推送，通过动态负载均衡、隔离部署、LXC虚拟化和监控报警等多种机制确保系统 的高可用，通过高可用消息队列、自动重连和ACK等机制实现消息可靠性（QoS1），并提供SDK方便产品和应用接入。 本文将在介绍消息推送服务相关功能/非功能特性的基础上，就系统为实现高可用进行的架构设计及部署方案进行探讨。 一、系统特性 1.1 功能特性 提供服务端SDK和各类终端SDK简化产品接入 对接入的产品服务端和终端进行安全认证 支持跨产品消息推送 支持广播、私信、组播、附件推送等多种消息推送方式 根据自定义条件筛选终端用户进行推送 支持IOS、Android、Web、PC、智能设备等多种终端 针对典型应用场景的各种解决方案 对接入的各产品进行统一配置管理 对推送效果进行统计 系统运行时监控及异常报警 1.2 非功能特性 消息可靠性满足QoS1 各种消息推送方式互不阻塞 具备快速水平扩展能力 系统高可用，无单点故障 异常隔离不扩散 消息推送路径跟踪及快速故障诊断 服务质量实时监测 易运维 支持C5000K高并发

2019年10月24日，组委会正式发布了China .NET Conf 2019中国 .NET 开发者峰会的主题内容。 2014年微软组织并成立.NET基金会，微软在成为主要的开源参与者的道路上又前进了一步。2014年以来已经有众多知名公司加入.NET基金会，Google，微软，AWS三大云厂商已经齐聚.NET基金会，在平台项目中，.NET平台上有87％贡献者其实并不在Microsoft工作。为了将.NET基金会变成一个更加多样化和成员驱动的组织，微软把.NET 的发展真正交给社区，为了让OSS真正蓬勃发展。 在中国这几年时间里我们不再局限于单打独斗的开源，我们通过协作来推动.NET开源项目和社区的发展，我们在github上成立了中国的开源组织dotnetcore，我们在全国各大城市有.NET 俱乐部定期举办活动。9月23号的2019年.Net Conf，今年它比以往任何时候规模都更大， .NET Core 3.0已经在大会上正式发布。中国区的活动也正式提上日程，好多年都没有像这样规模的社区大会，今年举办 .NET社区的中国峰会。预计1000人规模，覆盖中国 14个城市的.NET 社区及机构。 我们从开始筹备2019 中国.NET 开发者峰会已经有好一段时间，从确定主题到寻找举办地，我们都是在业余时间进行，这次完全由中国.NET社区自发组织的大会，我们希望通过这次大会汇聚中国

传统作法 在之前实现的config-server基础上来实现高可用非常简单，不需要我们为这些服务端做任何额外的配置，只需要遵守一个配置规则：将所有的Config Server都指向同一个Git仓库，这样所有的配置内容就通过统一的共享文件系统来维护，而客户端在指定Config Server位置时，只要配置Config Server外的均衡负载即可，就像如下图所示的结构 注册为服务 把config-server也注册为服务，这样所有客户端就能以服务的方式进行访问。通过这种方法，只需要启动多个指向同一Git仓库位置的config-server就能实现高可用了。 config-server配置 pom.xml依赖 <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> </dependencies> 在 application

某厂面试归来，发现自己落伍了！>>> 1.前言 随着业务的发展，MySQL数据库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作的开销也会越来越大；另外，无论怎样升级硬件资源，单台服务器的资源（CPU、磁盘、内存、网络IO、事务数、连接数）总是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。 分表、分库和读写分离可以有效地减小单台数据库的压力。 本文主要针对业界主流的数据库中间件的实现、功能、成本等方面进行对比，总结数据库中间件的实现方式，并展望未来的可能发展。 2. 实现方式 一般来说，对于数据库中间件，可以在以下六个层次做切入。 2.1 代码层 在同一个项目中创建多个数据源，采用if else的方式，直接根据条件在代码中路由。 Spring中有动态切换数据源的抽象类，具体参见AbstractRoutingDataSource。 如果项目不是很庞大，使用这种方式能够快速的进行分库。但缺点也是显而易见的，这种海量的代码侵入是绝不能被接受的。 而且当查询结果返回时，需要对跨库、聚合等查询结果进行归并，开发工作量非常巨大。 这种方式了解一下即可，一般不会去使用。 2.2 框架层 主要是修改或增强现有ORM框架的功能，在SQL中增加一些自定义原语或者hint来实现。 常见的比如实现一些拦截器（比如Mybatis的Interceptor接口）

RHCS提供的三个核心功能 　　 高可用集群是RHCS的核心功能。当应用程序出现故障，或者系统硬件、网络出现故障时，应用可以通过RHCS提供的高可用性服务管理组件自动、快速从一个节点切换到另一个节点，节点故障转移功能对客户端来说是透明的，从而保证应用持续、不间断的对外提供服务，这就是RHCS高可用集群实现的功能。 　　 RHCS通过LVS（LinuxVirtualServer）来提供负载均衡集群，而LVS是一个开源的、功能强大的基于IP的负载均衡技术，LVS由负载调度器和服务访问节点组成，通过LVS的负载调度功能，可以将客户端请求平均的分配到各个服务节点，同时，还可以定义多种负载分配策略，当一个请求进来时，集群系统根据调度算法来判断应该将请求分配到哪个服务节点，然后，由分配到的节点响应客户端请求，同时，LVS还提供了服务节点故障转移功能，也就是当某个服务节点不能提供服务时，LVS会自动屏蔽这个故障节点，接着将失败节点从集群中剔除，同时将新来此节点的请求平滑的转移到其它正常节点上来；而当此故障节点恢复正常后，LVS又会自动将此节点加入到集群中去。而这一系列切换动作，对用户来说，都是透明的，通过故障转移功能，保证了服务的不间断、稳定运行。 　　 RHCS通过GFS文件系统来提供存储集群功能，GFS是GlobalFileSystem的缩写，它允许多个服务同时去读写一个单一的共享文件系统

　　今天老大跟我讨论说，没有看到过一篇够全面体系的高可用的文章。谈到高可用，基本都是以偏概全的文章。今晚抽空想了一下这个问题。 　　高可用我另一个更资深老大其实总结的很全面了：别人死我们不死，自己不作死，不被队友搞死。 　　然后就是怎么别人死我们不死：最好就是别人的东西和我们没关系，就是去依赖。如果实在有依赖呢，那就尽量弱依赖。弱依赖有需要被依赖方的返回结果和不依赖返回结果两种。需要结果就要请求后回调，不需要就直接异步化。另外要做好超时和重试、蓄洪、限流、熔断、降级。如果只能强依赖呢，人家死了，那就我们报错，但是我们不死。这也需要设置合理超时和重试、蓄洪、限流、熔断、降级。人家又复活了，我们也要立即恢复。 　　基于对依赖的策略总结如下： 　　依赖策略里涉及到容灾的问题。容灾需要解决两个方面的问题： 　　这里就怎样快速失败和安全失败举一个例子。java.util包的容器的迭代器，在每次迭代的时候，其内部实现都会去判断modCount变量是否为expectedModCount的值。是的话就继续遍历，否则就抛出异常，终止遍历。这是一个快速失败的典型例子。 　　而采用安全失败机制的集合容器，在遍历时不时直接在集合内容上访问的，而是先复制原有集合内容，然后在拷贝的集合上进行遍历。所以再遍历过程中对元集合所作的修改并不能被迭代器检测到，不会触发异常。但是这时遍历对原集合的修改是不感知的。 　

158人阅读 一，高可用集群概念 1，什么是高可用性？ “高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性； 主要是避免软件、硬件、人为造成的故障对业务的影响降低到最小程度，以保证服务不间断地运行； 2，高可用性知识点 （1）计算机的高可用性 计算机系统的可用性用平均无故障时间（MTTF）来度量，即计算机系统平均能够正常运行多长时间，才发生一次故障。系统的可用性越高，平均无故障时间越长。 可维护性用平均维修时间（MTTR）来度量，即系统发生故障后维修和重新恢复正常运行平均花费的时间。系统的可维护性越好，平均维修时间越短。 计算机系统的可用性定义为：MTTF/(MTTF+MTTR) * 100%。由此可见，计算机系统的可用性定义为系统保持正常运行时间的百分比。 描述 可用性级别 年度停机时间 基本可用性 99% 87.6小时 较高可用性 99.9% 8.8小时 具有故障自动恢复能力的可用性 99.99% 53分钟 极高可用性 99.999% 5分钟 （2）负载均衡服务器的高可用性 为了屏蔽负载均衡服务器的失效，需要建立一个备份机。主服务器和备份机上都运行High Availability监控程序，通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时