概念梳理

ceph(分布式存储)特性：
可扩展性：可以分布在几百台的集群规模，而已性能会随着集群规模的增长而增长；
低成本：分布式存储系统具有自动容错和自动负载均衡机制；
高性能：无论是针对整个集群还是单台服务器，都要求分布式系统具备高性能；
易用：分布式存储系统需要对外提供易用的接口，另外，也要求具备完善的运维、监控工具，方便与系统进行集成；
Hadoop HDFS：大数据分布式文件系统
适用于数据吞吐量大的访问需求；数据在相同节点上以复制方式进行存储以此来实现数据合并的计算目的；采用将处理任务迁移到物理节点的方式来降低网络I/O;
ceph工作原理：
首先会有一个完整一个的文件系统file，我们要存储的数据都会被切分成对象，这个对象就是object，所以file会被切分成很多对象存储到object，每个对象都有一个唯一的oid，随后往下便是pgs，pg就类似于数据库中的索引，每个对象都会映射到固定的pg中，所以当我们需要寻找一个对象中，只需要先寻找到对象所属的pg即可，每个对象所属的pg都有唯一的pgid，最后pg会根据管理员设置的副本数量进行复制，随后通过crush算法存储到不同的osd节点上，第一个osd节点便是主节点，其余为从节点；

mysql主从复制：
mysql主从复制是一个异步复制的过程，master中负责写入数据，并将数据存入二进制文件中，从库会通过IO线程去读取master库中的二进制文件，随后将数据存储到slave的中继日志；
redis三种集群方式：
1、主从复制：
从服务器连接主服务器并发送sync命令；
主服务器接到sync命令后开始执行bgsave命令生成rdb文件并使用缓冲区记录此后执行的所有写命令；
主服务器的bgsave执行完成后会像所有的服务器发送快照文件，但在发送期间继续记录被执行的写命令；
从服务器收到快照后会丢掉所有的旧数据，载入新的数据，也就是收到的快照；
从服务器快照发送完毕后开始向服务器发送缓冲区中的写命令；
从服务器载入快照完成后，开始接受命令请求，并执行来自主服务器缓冲区的写命令（从服务器初始化完成）
主服务器没执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令；
2、哨兵模式：
即有一个master和多个slave，当master宕机后，会在所有的slave中重新选举master，以便继续提供服务；redis中哨兵模式的作用就是监控redis系统的运行的状况，即监控主服务器和从服务器是否正常运行；主服务器出现故障时主动将从服务器转换为主服务器；
哨兵的工作方式：
每个哨兵进程每秒钟向集群中的master、slave或者其他的哨兵进程发送一个ping命令，若一个实例在规定时间内对于ping命令的回复时间超过down-after-milliseconds选项所指定的值时，则认为这个实例下线；
3、redis-cluster集群：
redis的哨兵模式基本可以实现高可用、读写分离，redis集群采用无中心结构，所有的redis节点彼此互联，内部使用二进制协议优化传输速度和带宽；节点的fail是通过集群中超过半数的节点检测失效时才生效；客户端与redis节点直连，不需要中间代理层。

elk
elasticsearch+Logstash+Kibana 可搭建海量日志分析平台；
ES负责日志检索和存储；Logstash复制日志的收集和分析、处理；Kibana：负责日志的可视化；
ES特点：
实时分析；可以做文件存储；文档导向；具有高可用性、易扩展的特点，同时还支持集群；

Apache：
支持通用网关接口；
支持httpd认证；
几乎可以运行在所有的计算机平台；
支持虚拟主机；
基于文件的配置；
可以做代理服务器；
Apache处理请求是阻塞型的；
nginx：
可以通过端口检测内部错误；
做反向代理；
对网络依赖性小；
可以处理静态文件；
支持正则匹配；
nginx处理请求是异步非阻塞型的；

七层负载均衡是基于URL等应用层的负载均衡，当请求经过七层时，七层负载接受虚拟URL的请求，根据调度算法转发到后端服务器；
四层负载均衡是基于ip等网络层的负载均衡，当请求经过四层，四层接受虚拟ip的请求，同时根据调度算法转发到后端服务器；

lvs：
优点：具有很好的伸缩性，可靠性和可管理性；
      抗负载能力强，对CPU资源消耗比较低；
      工作在四层，不占用流量，只拿来做分发，不会受到大流量的影响；
缺点：不支持正则匹配；
      不能做动静分离；
nginx：
优点：对网络的依赖性小，理论上能ping能通，就能使用；
      支持正则匹配；
      工作在七层，可以针对http应用做分发；
      能通过端口检测到内部错误；
      可以做代理服务器；
      遇到错误时可以返回故障状态码；
      配置简单；
      可以处理静态页面；
缺点：不支持URL检测，只支持http和email；
      对session的保持和cookie的引导能力相对欠缺；
      不能处理动态页面；
haproxy：
优点：支持通过URL检测内部错误；
      支持虚拟主机，session保持，cookie引导；
      支持tcp协议的负载均衡；
缺点：扩展性能有所欠缺；
     添加新功能比较费劲；

lvs三种工作模式：
nat模式：lvs将客户端发来的数据包的头部换成其中一台RS的ip，然后RS处理完成后将数据返回给lvs，lvs将源ip改成自身的ip，然后将目标ip改成客户端的，随后将处理结果返回给客户端；
tun：lvs将客户端发来的数据包封装成一个新的ip头标记，通过ip隧道转发给RS，RS收到后，首先将新的ip头标记解开，还原数据包，处理完成后将结果直接返回给客户端，不用再次经过lvs；
dr：客户端将请求发送到VIP，lvs将请求报文的目标Mac地址改成RS的Mac地址，在将请求转发给RS，RS响应后直接将结果返回给客户端；

Keepalived：
Keepalived使用vrrp路由冗余协议，主要目标是路由器双机，同时将具有相同功能的路由器组成一个路由器组，在这个组里，会有一个master和多个backup，master会定时向backup发送组播信息，若在某一段时间内，backup接收不到来自master的组播的信息，则认为master已经宕机，然后会在这个backup中重新选举出新的master来保证服务的正常运行；
Keepalived支持脚本，对于脚本没有限制；
配置和使用简单；
使用vrrp来选举和通信；
目标是路由器双机；
Keepalived主要用于集群倒换，基本没有管理功能；
多用于lvs；
heartbeat：
支持使用脚本，但对脚本有束缚；
通过心跳检测来进行通信和选举；
功能更加强大；
基于主机或网络服务的高可用方式；
目的是用户的service双机，多用于业务的高可用；

nginx_upstream容错机制：
当有一个请求过来时，会转发到后端服务器去处理，若这个后端服务器发生故障，则会返回状态码，那么，在这段时间内，再有请求过来时，将不会转发到这个后端服务器；

nginx负载均衡调度算法：
轮询：每个请求按照时间顺序逐一发送给后端服务器，如果后端服务器宕机，则自动剔除，让用户的访问不受限制，这种方式成本低，简便，但是可靠性也低；
权重：权重值越大被分配到的几率也就越大，这主要用于后端服务器性能不均的情况下，达到合理分配利用主机资源的目的；
fair：根据页面大小和加载时间的长短进行负载均衡，响应时间短的被分配到的几率越大，也就是根据后端服务器的响应时间来分配请求；
ip_hash：每个请求根据ip形成一个hash表，当每次请求来自相同ip的访问就固定访问到一个后端服务器，可以解决session共享短的问题；
url_hash：每个请求根据URL形成一个hash表，当每次请求来自相同URL的访问时就固定访问到一个后端服务器，可以进一步提高后端缓存服务器的效率；

平滑发布：
在发布的过程中不影响用户使用，系统不会因此对外停止服务，不会造成用户短暂性无法访问，当服务器只有一台的时候，只能是平滑发布；
蓝绿发布：
首先在项目逻辑上分成AB组，在项目系统时，首先将A组从负载均衡中摘除，B组继续对外进行服务，A组进行新版本的部署，当A组升级完毕后，A组重新接入负载均衡，B组从负载均衡中摘除，A组对外提供服务，B组升级完毕后重新接入负载均衡，当AB完全升级完毕，对外提供服务；
特点：
若升级出现问题，影响范围大；
发布策略简单；
用户无感知，平滑过渡；
升级/回滚速度快；
缺点：
需要准备正常业务资源的两倍服务器以上，防止升级期间单组无法承受业务突发；
短时间内浪费资源成本；
基础设施无改动，增大升级稳定性；
灰度发布：
灰度发布只升级部分服务，即让一部分用户继续使用老版本，一部分用户使用新版本，若调研用户对新版本没什么意见，则扩大投放范围；
特点：
保证业务系统的稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；
新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
用户无感知，平滑过渡；
缺点：
对自动化要求高；
部署过程：
从LB摘掉恢复服务器，升级成功后在重新加入LB；
少量用户流量到新版本；
如果灰度服务器测试成功，在升级剩余服务器；
滚动发布：
滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级到新版本；
特点：
用户无感知，平滑过渡；
节约资源；
缺点：
部署时间慢，取决于每阶段的更新时间；
发布策略麻烦；
无法确定OK的环境，不易回滚；
部署过程：
先升级一个副本，主要做部署验证；
每次升级副本，自动从LB上摘掉，升级成功后自动加入集群；
事先需要有自动更新的策略，先从LB摘掉新版本，在升级老版本；
自动化要求高；

zabbix	prometheus
后端用C开发，界面用PHP，定制化难度高	后端用golang开发，前端是Grafana，json编辑就可以解决，定制化难度较低
监控数据存储在关系型数据库内，如MySQL，很难从现有的数据中扩展维度	监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合
安装简单，zabbix-server一个软件包中包括了所有的服务端功能	安装相对复杂，监控、告警界面都属于不同的组件
集群规模上限为10000个节点	支持更大的集群规模，速度更快
更适合于监控物理机环境	更适合云环境的监控，对OpenStack、k8s有更好的集成
图形化界面比较成熟，界面上基本能完成全部的配置操作	界面相对较弱，很多配置需要修改配置文件