集群分布式及互联网架构

Linux Virtual Server

杂谈

2020的新的大纲和2019的都是匹配的

• 用户层

用户 (不同地区,不同系统,不同硬件设备){	
	通过{无线/有线}网络访问网站
}

• 服务层-用户量大，构建相对复杂的环境

  • CDN网络模块

    cdn(不同地区用户){
    	事先把静态页面缓存到cdn服务商的服务器上
    	用户访问页面
    	承担大部分的静态页面和图片请求，可以极大的降低服务器压力
    	 只有最新的资源和动态资源cdn服务器上是没有的，只有用户在访问这些资源的时候才需要访问互联网
    }
    

  • 外部-防火墙模块

    前端有防火墙模块，这个模块在企业中是必不可少的设备
    
    会购买专业的硬件防火墙，iptable只是个软件防火墙
    
    为了容错，硬件防火墙都是两道防火墙，并且是并行的
    # 并行:从互联网进入是两条线路，联通和电信两条线做负载，联通挂了还有电
    信的，并且每条线路后放一道防火墙
    # 这样进入到企业的内部必须先通过防火墙才可以
    # 到达防火墙后，需要让用户的请求进入企业的web服务器（apache/nginx）
    # 但是企业内部的服务有很多
    # 由很多小模块/服务构成，这些模块是分布在不同的服务器上的
    # 防火墙上的IP是真正大的公网IP
    

  • 内部-一级反向代理调度模块

    # 请求进入企业内部的时候需要调度器
    LVS/HAproxy 高可用四层负载
    # HAproxy（后面学，专业级的调度器
    # 避免单点失败，至少要两个调度器
    # 企业一般都是两个
    
    会配置vip
    # virtual IP
    用户访问的时候会访问虚拟的地址，可能会运行在第一台，也可能会运行在第二
    台机器上，一个飘动的地址
    # VIP具体在哪台上看配置只能运行在一台机器上
    不管哪台机器上，用户访问的时候，发请求是发到vip上的
    # 这个vip和DNS解析出来的IP不是同一个
    # DNS解析出来的IP是防火墙上的IP
    
    用DNT把防火墙上的公网IP映射成企业内部的VIP
    # 所以互联网上的用户根本看不到企业内部真正的地址，看到的都是防火墙的地
    址
    
    # 用户访问防火墙的公网地址，公网地址映射成私网VIP地址，转发给LVS，通过
    调度模块往企业内部网络调度，再根据企业的各种服务进行各种资源的调度
    
    # 这个调度到内部的其他模块上，根据需要访问的数据
    

  • 内部-其他服务模块

    因为访问一个网站的时候有很多的页面，不同的页面代表不同的服务

  # 案例
  访问www.jd.com/xxx
  xxx对应的是不同的服务或者资源
  根据用户不同请求的URL,调度模块讲用户的请求调度到后端不同的服务上，后面会
  有很多不同的子服务
  

  不同服务模块
    基础模块
    	内部DNS模块
    	内部NTP模块
    	Harbor模块-容器仓库（类似yum仓库-放软件的）
    	时间同步模块等
    业务模块
    	nginx七层反向代理-复杂架构
    	LA/NMP门户网站模块-简单架构
    资源模块
    	静态资源模块
    		静态资源服务器-nginx
    		静态资源缓存服务器
    			jpg
    			html
    	动态资源模块
    		java-tomcat
    			java资源响应模块
    				mysql主从
    				mongoDB
    				redis
    			java组
    				单体应用组
    				生产者组
    				消费者组
    				微服务组
    		php-fpm
    存储模块
    	  	开源存储服务器-NFS，ceph
    	商业存储服务器-NAS，SAN
    健康性模块
    		分布式监控平台-promethous/zabbix
    生产模块
    		持续集成和持续部署-jenkins+gitlab
    记录模块
    		日志收集-ELK
    其他模块-目前无法分，这个应该是os层的
    		容器管理-docker，k8s（新）/openstack（老）
  

  • 内部-二级反向代理调度模块-调度后端资源

    # 案例
    访问www.jd.com/xxx
    xxx对应的是不同的服务或者资源
    根据用户不同请求的URL,调度模块讲用户的请求调度到后端不同的服务上，后面会有很多不同的子服务
    
    内部的调度采用nginx做反向代理
    # 一位用户的访问量很多，只是用一台LVS是承受不了访问的，要用nginx做更细节的调度，做第二次的反向代理的调度
    # 所以总的代理内部还有其他的调度
    

    案例:实现基于请求的动静分离

    静态资源放在一些服务器上
    动态资源放在一些服务器上
    # nginx更擅长这种动静调度，apache也可以但是不怎么用
    # 比如说要访问动态资源php，就往动态资源服务器上调度
    # 比如说要访问静态资源jpg,html，就往静态资源上调度
    
    
    调度到后端的静态资源缓存服务器/静态资源服务器
    # 比如说用户上传了一个图片，最后会放在一个集中的存储服务器上
    # 下次再访问会通过nginx进行静态调度，最终从存储服务器上得到静态页面
    

  • 内部-资源模块

    • 动态-fpm模块-fpm
    • 动态-java模块-tomcat

    根据不同业务的请求，通过LVS调度后，再通过nginx调度动态资源java资源，哪 个业务的java资源，不同业务的java资源跑在不同的组服务器上

    单体应用组
    生产者组
    消费者组
    微服务组
    

    一般来说，nginx一台调度动态资源，后面可能要5台甚至更多提供java组服务

    • java资源响应模块

      • mysql主从

      mysql是关系型数据库，性能比较差，可以用redis来提升整个服务器的性能，可以讲mysq的数据缓存到redis里

      • redis

      数据缓存服务器集群，用来提升关系型数据库性能

      将MySQL的数据缓存到redis的服务器上，将来用户要访问的时候可以从redis
      的缓存中的得到数据，而不需要在mysql中执行复杂的语句查询，因为mysql的
      语句查询速度是非常慢的
      
      redis是基于内存的，相当于一个大内存，一台存储在单点失败问题，所以要
      用集群，很多都是集群，tomcat，redis，mysql都是集群
      

      • 分布式注册中心-zookeeper

      类似NFS中的生产者和消费者，到底从哪个机器上的到这个服务

      现在流行的微服务概念，将一个大服务拆分的很细，由多个模块构成
      
      比如一个博客网站里面有很多功能功能，以前是放在一个机器上的，微服务的
      盖帘就是把这这些功能拆开，放到一个专门的模块里，放到不同的服务器上，
      这些功能是分散在不同大的服务器上很多很多，这样涉及到的主机就很多，用
      户在访问的时候，原来是在一个机器上，互相访问很简单，但是不同的机器之
      间怎么访问，就涉及到服务之间的相互访问，比如rpc，远程过程调用
      
      访问的话，就涉及到远程过程调用，怎么找你啊，就靠分布式的注册中心，zo
      okeeper
      
      这个应用可以把我们的服务先注册上去，那么要访问什么服务的时候，就可访
      问zookeeper，类似一个114查询台，告诉你哪个机器上提供了什么服务
      
      企业中要实现服务之间的通讯SOA，SOA是微服务的前身，SOA已经是前一代大
      的技术了，微服务是比SOA更小的粒度
      

      • 消息队列-kafka/rabbitMQ/rocketMQ

      各个服务之间要进行通讯，就要用到消息队列
      
      比如说有个服务器提供数据，另一个服务器使用数据，把提供数据的数据发送
      到消息队列上，另一个服务器去消息队列获取数据
      
      也是一个数据概念，用户将数据写进去，再读出来，只是用了一排队机制
      

  • 内部-健康性模块

    • 分布式监控平台-zabblix

    监控cpu磁盘利用率等
    
    但是这个小服务未来不是跑在主机上，而是跑在类似容器上，容器可以理解为一
    个小的虚拟机，但是容器比虚拟机更节约资源，相当于机器上的小应用，占用的
    资源特别小，一台机器上可以运行很多很多个小容器，小容器占用的资源比虚拟
    机小很多，在电脑上可以跑10个虚拟机，但是可以跑30-40个容器，粒度可以更
    小，更服务前面的微服务，不需要专门的放在一个虚拟机里，放在容器里就可以
    了
    
    就需要容器的管理，容器也是虚拟化的一个应用，openstack就是一个开源的虚
    拟化的管理软件，可以用来管理虚拟机，用openstack可以轻易的在很多服务器
    上创建虚拟机，迁移虚拟机，实现虚拟化的管理，vm虽然实现了虚拟化的，但是
    是单机方式管理，所以需要一个单机的虚拟化的管理服务器，但是openstack管
    理的是虚拟机，对资源消耗更大，因为每个虚拟机都需要专门的内核，每个虚拟
    机相当于一个物理机，有自己的一套内存，cpu，存储等，都是独立的，相对消
    耗资源，结果上面就跑一个小服务，相当于投入产出不成比例，跑的服务结果没
    有操作系统占用的资源多，相当于开了一个自重10吨的小货车，结果拉了一吨的
    货，成本过高，所以不用虚拟机的机制，用容器，消耗的资源更少，可以自重很
    轻，相当于1千斤的小车，但是可以跑一吨的大服务，本身特别省资源，并且可
    以跑很多，那么要管理容器的话，就要用到容器技术，容器技术主流的是docker
    ，docker只是解决了类似vm的单机，一台机器上可以用doker管理单机上的容器
    
    但是企业有很多的服务器，每个机器上都需要跑容器，那么多的容器管理，需要
    一个集中的，大规模的网络式的管理，用k8s管理分散在很多服务器上的容器
    
    之前钉钉用户量特别大，除了要增加物理服务器，还要扩容大量的容器，每个物
    理服务器上跑个20-30甚至更多的容器，容器要迁移和管理用k8s，这些是大力推
    广的技术，不代表很多企业都在用，很多的企业也在用openstack
    

  • 生产模块

    • 持续集成和持续部署-jenkins+github（放程序员开发的软件的）

      尤其互联网的时代来临，每个应用的生命周期相对来说更迭很快，要抢占市场，一切以市场为导向，要快速大的去做升级
      
      一天开发人员可能就会出好几个版本，上午下午晚上
      
      现在想让开发人员开发的软件要快速上线，就要用到持续集成和持续部署，要用到jenkins和gitlab这一套管理系统，gitlab是管理软件版本的，比如说原来是V1.1版，之后有V1.2版，所有版本都要有，每次阶段性的生成一个新版本，不断升级，gitlab就是一个仓库
      
      软件要部署到各个机器上，先把软件传给jenkins，之后在jenkins上制定部署策略，发布到生产和测试环境中，生产和发行分离
      

    • 记录模块

      • 日志管理-ELK

        企业里有很多的服务器，有大量的日志，可以说大数据时代里，日志就是黄
        金， 
        收集各种服务器上的数据加以分析，有专门的大数据分析工程师-很吃香
        
        有大数据运维的岗位很吃香，通过各种渠道把数据抓取过来，得到很多有商
        业价值的东西
        
        将来从个人发展来说可以偏重某个方向的可以深入学习
        
        方向:DBA，大数据，安全等方向深入研究
        

• LNMP架构

  比如说搭建了一个企业的宣传页面，不用太复杂，用LN/AMP就够了
  

• 跳板机

  用于远程连接的，比如在外出差，怎么远程做运维工作
  

总结:现在学的只是一部分，后面学的东西还有很多

Linux Virtual Server

LVS调度器，所有服务的入口

原理和复杂，配置很简单

1.集群和分布式

因为现在互联网访问会短时间爆发性增长，如果只是依靠摩尔定律两年性能翻番，太慢了

系统性能扩展方式:

• Scale UP：垂直扩展，向上扩展，增强，性能更强的计算机运行同样的服务
• Scale Out:水平扩展，向外扩展，增加设备，并行的运行多个服务调度分配问题，CLuster

垂直扩展不再使用:

随着计算机性能大的增长，其价格会成倍增长
单台计算机的性能是有上线的，不可能无限制地垂直扩展，而且性价比不高
多核cpu意味着即使是单台计算机也可以并行

问题:为什么不一开始就并行化技术

1.1 集群Cluster

Cluster:集群，为解决某个特定问题将多台计算机组合起来形成地单个系统(好几台机器对外是一个服务)

CLuster分为三种类型:

• LB:load balancing,负载均衡

  多个主机组成，每个主机只承担一部分访问，就是均衡负载，具体怎么均衡，看策略

  案例:mysql主从复制，mysql主服务器负责写，其他从负责读

  案例:LVS负载均衡调度器，LVS接收用户的请求，把请求调度到后端的服务器上，每个服务器承担了部分的请求，这就是负载均衡调度器，如果就一台LVS，要针对LVS提供高可用性，解决LVS的单点失败问题，用keepalive来拯救LVS，弥补不LVS的高可用性问题，光靠LVS不行，必须要整合keepalive来解决高可用性问题，通常都是配合使用的，是个cp

• HA:High Availiablity,高可用，避免SPOF(single Point Of failure)

  相关避免但单点失败的技术:
  raid
  读写分离-mysql读从服务器，mysql写主服务器，mysql主服务器down，从服务器升
  级，MHA技术-自动将其中一个从服务器提升为主服务器
  

  SLA:服务等级协议（简称:SLA，全称：service level agreement）

  是在一定开销下为保障服务的性能和可用性，服务提供商与用户定义地一种双方认可大的协定。通常这个开销是驱动提供服务质量地主要因素。再常规地领域中，重视设定所谓地三个9，四个9来进行表示，当没有达到这种水平的时候，就会有一些列的惩罚措施，运维，最主要的目标就是达到这种服务水平

  MTBF:Mean Time BetweenFailure 平均无故障时间-正常时间

  MTTR:Mean Time To Restoration (repair) 平均恢复前时间-故障时间

  A=MTBF/（MTBF+MTTR） (0,1):99%,99.5%.99.9%,99.99%,99.999% 计算高可用性的比值

  1年=365天=8760小时
  99.9=8760*0.1%=8.76小时
  99.99=52.6分钟
  99.999=5.26分钟
  

  停机时间又分两种，一种是计划内停机时间（更换硬件），一种是计划外停机时间（故障），而运维主要关注计划外停机时间，互联网公司判断运维的kpi，就是SLA

• HPC：High-performance computing，高性能www.top500.org

  这个和我们不相关，LB，HA和我们相关

  接下来学的LVS属于LB

1.2 分布式系统

分布式存储:Ceph,GlusterFS,FastFS,MogileFS

将不同的数据分散到不同的服务器上
	比如大众点评，传的图片将来怎么保存，如果都放到一台上面，服务器挂了怎么
	办，而且性能也不行，要解决容错和性能问题怎么办，用分布式存储
	大众点评6台服务器，比如上传了a.jpg，在3个服务器上各放一份
	b.jpg,再放3份，每个服务器都有一部分，每个服务器都有三分拷贝
	如果是视频，先拆分，拆成10M小块，第一个小块分放三分
	现在用的百度云用的就是这个原理，背后的算法也很复杂
	
大众点评早期使用的是MogileFS，现在用的不太多了，现在主流用Ceph

分布式计算:hadoop，Spark

当用户需要大量的计算，一个一个去算，太慢了，每个子服务器算一点

分布式常见应用

• 分布式应用-服务按照功能拆分，使用微服务

• 分布式静态资源-静态资源放在不同的存储集群上

• 分布式数据和存储-使用key-value缓存系统

  redis搭建的集群-主要放key-value值
  	用户请求过来，如果现在又三台redis，请求与3取模，如果是1找第一台数据
  	但是存在一个问题，如果有一台挂了，三分之一数据就没了，存在单点失败问题
  	为了解决这个问题，redis有自己的技术，每个服务器用主从技术容错
  	redis真正企业中用要用到6台
  mysql的数据库，每个服务器放的是一样的东西
  
  redis和mysql类似主从，虽然用的软件不一样，但是逻辑上就那一套东西，只是软
  件选型和配置不太一样
  

• 分布式计算-对特殊业务使用分布式计算，比如hadoop集群

以前说dns的时候涉及到分布式，虽然dns服务器都提供dns服务，但是提供的具体内容不一样

1.3集群和分布式

单机结构：1个全栈老实人累如狗
集群结构：2个全栈老实人凑合过-会涉及到扯皮问题，并且不精通
分布式:后端攻城狮+前端攻城狮-男女搭配干活不累-有很多岗位，并且互相不能代替
运维：发布程序，岗位和不同的岗位会有沟通
总结:随着发展，全能的人早期可能比较好，什么都能干，但是性能和容错并不好，
因为什么都要干，按照流程干，中期，一个人忙不过来，那就两个人干，实现荣作，
但是性能依旧不好，因为都觉得自己什么都能干，如何去配合很不好，后期，长久的
配合中，前后端分离，服务细化，实现分布式，每个人干一点，然后每个环节再集群
，实现容错，这样性能不错，容错也有了，但是成本比较高，所以初期全能可以，但
是后期一定要有所偏向，实现配合，纵深发展，将串/并流程分布式实现，并且每个
环节实现集群，以及主从容错之后根据业务量和规模以及预算，对整体进行平衡，将
关键的环节实现集群，对主节点实现主从容错

比如一个业务:电商网站
需要项目经理-管理整个项目
需要策划-规划网站如何布局-画出草图
需要美工-根据草图，画出整个UI，最终效果图就这样-给策划-策划觉得ok-交给前端页面工程师
需要前端开发-根据UI，用三件套来实现-虽然前端实现了，但是数据从那里来-数据从后端来
需要后端开发-有java/php等等，后端开发完了，要放数据
需要dba-专业的数据库团队来维护

整个网站就搭建起来了，但是搭起来了，需要运维来保证业务的正常使用
需要运维-

网站上线后信息从哪里来，需要写文章，宣传资料
需要编辑-一天要一个完成量

之后还要推广
需要seo-优化

之后还要运营/市场这个网站
需要运营

之后还需要销售团队
需要销售


所以：在企业中真正实现一个网站是非常麻烦和复杂的

分布式：比如说微服务，将会员积分模块拆出来作为一个服务，然后既有前端也有后
端，作为一个整体，实现会员管理，但是要把这个事做好，干脆也不分什么前端后端
了，直接就是全栈，干脆都干了，相对比较方便，不像前端后端有局限性

集群:同一个业务系统，部署在多台服务器上。集群中，每一台服务器实现的功能没有差别，数据和代码都是一样的

分布式:一个业务被拆成多个子夜吴，活着本身就是不同的业务，部署在多台服务器 上。分布式中，每台服务器实现的功能是有差别的，数据和代码也是不一样的，分布 式每台服务器功能加起来，才是完整的业务

分布式是以缩短单个任务的执行时间来提升效率的，而集群是通过提高单位时间执行 的任务数来提高效率的。

对于大型网站，访问用户很多，实现一个群集，在前面不是一个负载均衡服务器，后 面几台服务器完成同一个业务如果有用户进行相应业务访问时，负载均衡器根据后端 哪台服务器的负载情况，决定由哪台去完成响应，并且一台服务器跨了，其他服务器 可以顶上来。分布式的每个节点，都完成不同的业务，如果一个节点跨了，那么这个 业务可能就会失败，分布式本身没有容错功能

1.4 集群设计原则-了解

可扩展性-集群的横向扩展能力

可用性-无故障响应使劲按

性能-访问响应时间

容量-单位时间内的最大并发吞吐俩量（C10K并发问题）

1.5 集群设计实现

1.5.1 基础设施

提升硬件资源性能-从入口防火墙到后端we server均使用更高性能的硬件资源

上线服务器的时候，一定要和老板打报告，要更高性能的服务器，不然以后业务量大
起来，顶不住了，将来背锅的还是运维，如果老板不批的话，将来出问题了还有的说
，一定要超前一点配

多域名-DNS轮询A记录解析

比如京东，首页面有大量的html，css，js文件，并不都是由一个服务器提供的，很
多服务器，放在很多的域名下的

多入口-将A记录解析到多个公网IP入口

www.jd.com对应的IP可能不是一个IP，一个域名对应多个A记录

多机房-同城+异地容灾

大公司做同城容灾
超大公司异地容灾

CDN（Content Delivery Network）-基于GSLB（Global Server Load Balance）实现全局负载均衡，如DNS

1.5.2 业务层面

分层:安全层，负载层，静态层，动态层（缓存层，存储层）持久化和非持久化

安全层：防火墙
负载层：前面有调度
动静分离
缓存：redis
存储持久化:mysql

分隔:基于功能分隔大业务为小服务

大服务分割成小服务，并实现小服务的快速复制
使用容器技术，快速copy，生成小的相同的容器服务，并且把容器分发到各个服务器上
实现所谓的扩容

但是需要提前先分割业务

分布式:对特殊场景的业务使用分布式计算

1.6 LB Cluster负载均衡集群

1.6.1 按实现方式划分

• 硬件

  F5 Big-IP

  非常有名，很多大公司，从防火墙进来后，就是F5 BIg-ip
  是一个调度器，功能和性能都特别好，也非常贵
  当时大众点评一个机器70多万，并且买一个还不行，要实现容错，光这一个铁盒子200万出去了
  互联网既挣钱又烧钱
  
  nginx被F5收购了，有一个就在F5工作，关于F5的相关可以问他
  

  Citrix Netsaler

  A10 A10

• 软件

  LVS：linux virtual server,阿里四层SLB（load balance）使用

  nginx:支持七层调度，阿里七层SLB使用Tengine（nginx的二次开发版）

  nginx起家的功能是web服务器
  nginx功能很强，也可以做代理服务器
  
  所以，有的公司觉得通用就用他就可以了，从专业角度来说，在代理方面ha更专业
  

  haproxy：支持七层调度（专门的调度器，功能更全面）

  ats：Apache Traffic serer，yahoo捐助给apache

  perlbal：perl编写

  pound

1.6.2 基于工作的协议层次划分

所谓的四层，就是基于tcp/ip协议传输层以下的进行调度
实现端口号和IP地址调度
LVS只能实现传输层和传输层以下的调度，只能根据端口号和IP进行调度
cookie调度实现不了，因为cookie是应用层的

haproxy,nginx也能做四层的调度，但是这两个服务强大在应用层也能做，七层调度
可以针对某种协议调度，可以针对http调度，也可以针对php协议（fastcgi协议）都
可以做

• 传输层（通用）:DNAT和DPORT

  LVS：

  nginx:stream

  haproxy:mode tcp

• 应用层(专用):针对特定协议,常称为proxy server

  http:nginx,httpd,haproxy(mode http),..

  fastcgi:nginx,httpd

  mysql:mysql-proxy

  mysql-proxy协议调度，mysql可以实现读写分离
  

1.6.3 负载均衡的会话保持

如何让用户得到同一个session信息
当用户请求发来时，用户被分配一个用户唯一标识的session
但是带来一个问题，用户发请求时，第一次访问a，第二次刷新页面，被调度器调度
到了第二台服务器上，则session信息就可以找不到了

1.session sticky:同一用户调度固定服务器

当用户发请求时，被调度到第一个服务器，生成一个session id，session 
id1通过cookie交给用户
有个send cookie的首播字段
当用户发起请求时，被调度到第二台服务器，b上没有session id 
，以为是个新客户，会分配一个新的session id2，原来的session id1就不用了
如果之后再调度到1，就又不认识了
这样就会导致频繁登陆的效果，为了解决这个问题，用session sticky
同一个请求往同一个服务器上调度
只要在调度器上能识别是哪个用户就可以了-阿里的内网登陆机制实现
对调度器来说，怎么知道你是同一个用户
c用户进入时，调度器（可能时ha，nginx，lvs三个其中之一）上
调度器上就会记录以下，我曾经把c调度到a上了，之后往同一个服务器上调度

如何识别出这次是c上次还是c呢，根据地址IP判断，但是根据ip地址判断是不是同一
个人，这个不准确
平时上网的时候，出去的使用用的都是同一个IP，教室里几百个人上网，出去用的都
是同一个ip，大量的用户认为都是c，这很不合理

这种昂是不准确，靠cookie，基于浏览器的，这个cookie是在浏览器里存的，当发请
求的时候，这个cookie会记录下来，下次同样的cookie来了就会往之前调度的服务器
上调度，更精准

教室里的人，哪怕1000个人去访问，但是浏览器的cookie是不一样的

有个要求，就是代理服务器能识别cookie
但是lvs识别不了，因为lvs是四层的，没有这个功能，lvs这个功能做不到

这种方式也有个缺点，大量的用户根据cookie进行调度
如果用户存在的服务器宕机了，下线了，cookie就失效了

之后有了另一种方法，session复制，产生了一个session id，不仅啊，上有，bc都有
不管发请求来了，都可以调度，但是又有个问题，abc上存放的内容都是一样的，比
较占用内存，一旦用户量比较大，每个服务器上都有一份，相当于拷贝了全部的内容
，每个服务器的压力很大的，但是session复制不适合大环境，三五台适合

还有一种方式用session 
server，session放在一个专门的服务器上，这个session不由自己生成，而是用专门
的数据库生成，用的比较多的就是redis，用户访问的时候，调度集中访问redis，进
而调度，但是又产生了一个新的问题，redis挂了，就凉了，redis实现容错，redis
集群，三个节点，每个节点只放其中一部分1/3，但是存在单点失败问题，再搭建从
节点，每个节点实现主从，后面做redis的时候就要用6个节点，tomcat都有这种技术
的

​ source IP:LVS sh算法（对某特定服务而言）

​ cookie

2.session replication:每台服务器拥有全部session

​ session multicast cluster

3.session server:专门的session服务器

​ Memcached，Redis

1.7 HA高可用集群实现

keepalived:vrrp协议

虽然lvs解决了高可用的lb问题，但是单点失败解决不了的，所以用keepalive
其他的方案,很少用到了，在centos5之前，但是centos67往后就不用了
Ais ：应用接口规范
	heartest
	cman+rgmanager（RHCS）
	coresync_pacemaker