一、Redis
1.redis重要性
1.速度快
Redis所有的数据都存放在内存中
Redis使用C语言实现
Redis使用单线程架构
2.基于键值对的数据结构服务器
数据结构:字符串,哈希,列表,集合,有序集合
3.丰富的功能
提供了键过期功能,可以实现缓存
提供了发布订阅功能,可以实现消息系统
提供了pipeline功能,客户端可以将一批命令一次性传到Redis,减少了网络开销
4.简单稳定
源码很少,3.0版本以后5万行左右.
使用单线程模型法,是的Redis服务端处理模型变得简单.
不依赖操作系统的中的类库
5.客户端语言多 C++,Nodejs等
6.持久化
RDB和AOF
7.主从复制
8.高可用和分布式
哨兵
集群
2.redis应用场景
1.缓存-键过期时间
缓存session会话
缓存用户信息,找不到再去mysql查,查到然后回写到redis
2.排行榜-列表&有序集合
热度排名排行榜
发布时间排行榜
3.计数器应用-天然支持计数器
帖子浏览数
视频播放次数
商品浏览数
4.社交网络-集合
踩/赞,粉丝,共同好友/喜好,推送,打标签
5.消息队列系统-发布订阅
配合elk实现日志收集
3.RDB和AOF优缺点
RDB: 可以在指定的时间间隔内生成数据集的时间点快照,把当前内存里的状态快照到磁盘上
优点: 压缩格式/恢复速度快,适用于备份,主从复制也是基于rdb持久化功能实现
缺点: 可能会丢失数据
AOF: 类似于mysql的binlog,重写,、每次操作都写一次/1秒写一次,文件中的命令全部以redis协议的格式保存,新命令会被追加到文件的末尾
优点: 安全,有可能会丢失1秒的数据
缺点: 文件比较大,恢复速度慢
如何选择：
好的，那我该怎么用？
通常的指示是，如果您希望获得与PostgreSQL可以提供的功能相当的数据安全性，则应同时使用两种持久性方法。
如果您非常关心数据，但是在灾难情况下仍然可以承受几分钟的数据丢失，则可以仅使用RDB。
有很多用户单独使用AOF，但我们不建议这样做，因为不时拥有RDB快照对于进行数据库备份，加快重启速度以及AOF引擎中存在错误是一个好主意。
注意：由于所有这些原因，我们将来可能会最终将AOF和RDB统一为一个持久性模型（长期计划）。
4.Redis主从复制
主从复制介绍
在分布式系统中为了解决单点问题,通常会把数据复制多个副本到其他机器,满足故障恢复和负载均衡等求.
Redis也是如此,提供了复制功能.
复制功能是高可用Redis的基础,后面的哨兵和集群都是在复制的基础上实现高可用的.
主从复制流程:
注意：做主从需要开启RDB
1.从节点发送同步请求到主节点
2.主节点接收到从节点的请求之后,做了如下操作
- 立即执行bgsave将当前内存里的数据持久化到磁盘上
- 持久化完成之后,将rdb文件发送给从节点
3.从节点从主节点接收到rdb文件之后,做了如下操作
- 清空自己的数据
- 载入从主节点接收的rdb文件到自己的内存里
4.后面的操作就是和主节点实时的了
5.Redis哨兵
Redis Sentinel 是一个分布式系统， Redis Sentinel为Redis提供高可用性。可以在没有人为干预的情况下阻止某种类型的故障。
Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）该系统执行以下三个任务：
1.监控（Monitoring）：
Sentinel 会不断地定期检查你的主服务器和从服务器是否运作正常。
2.提醒（Notification）：
当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3.自动故障迁移（Automatic failover）：
当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器
Sentinel 节点是一个特殊的 Redis 节点,他们有自己专属的 API(端口)
#哨兵工作原理
1.哨兵的成员是可以互相感知的，信息是共享的，每个节点都知道别的节点的状态
2.当主挂掉以后，哨兵会自动将主节点替换到别的从节点，将从节点变更为主节点.
3.当挂掉的节点恢复后，哨兵会将此恢复的节点默认设置成从节点。
4.当代码连接时候，代码会连接哨兵的节点，哨兵节点会把当前的主节点返回给代码，代码拿到主节点ip后再连接。
5.哨兵不存储和处理数据，只做监控和执行命令
6.redis集群安装部署-----基于主从的前提
Redis Cluster 是 redis的分布式解决方案，在3.0版本正式推出
当遇到单机、内存、并发、流量等瓶颈时，可以采用Cluster架构方案达到负载均衡目的。
Redis Cluster之前的分布式方案有两种：
- 客户端分区方案，优点分区逻辑可控，缺点是需要自己处理数据路由，高可用和故障转移等。
- 代理方案，优点是简化客户端分布式逻辑和升级维护便利，缺点加重架构部署和性能消耗。
官方提供的 Redis Cluster集群方案，很好的解决了集群方面的问题
#redis cluter
1.redis集群不管有多少节点，一共只有16384个槽
2.所有的槽都必须分配完毕才能工作，有一个槽没分配或者有问题，整个集群都不可用
3.每个节点上槽位的顺序无所谓，重点是槽位的个数
4.hash分片算法足够随机，足够平均，每个槽位获取的数据概率是一致的
5.不要去手动修改集群的配置文件
7.redis的2个故障案例
执行,reblance是出现#######,按下ctrl+c发现集群执行cluster info时.ok,但槽的状态有问题
解决思路:
1手动关闭:
连接对应的redis节点,执行cluster setslot 773 stable,
查询槽的状态已经恢复
cluster info
检查,有报错,
./redis-trib.rb check 10.0.0.51:6380
cluster info 状态ok,集群用fix,有问题,发现问题773槽位识别出现问题,其他节点上看0-773在6390上,6390上看而在6380上
2.删除两个问题槽位,6380,6390
cluster delslots 773
3.6390添加773
cluster addslots 773
发现大家看到的结果一致6390上,check.reblance ok
监控过期键
需求背景
因为开发重复提交，导致电商网站优惠卷过期时间失效
问题分析
如果一个键已经设置了过期时间，这时候在set这个键，过期时间就会取消
解决思路
如何在不影响机器性能的前提下批量获取需要监控键过期时间
1.Keys * 查出来匹配的键名。然后循环读取ttl时间
2.scan * 范围查询键名。然后循环读取ttl时间
Keys 重操作，会影响服务器性能，除非是不提供服务的从节点
Scan 负担小，但是需要去多次才能取完，需要写脚本
脚本内容：
cat 01get_key.sh
#!/bin/bash
key_num=0
> key_name.log
for line in $(cat key_list.txt)
do
while true
do
scan_num=$(redis-cli -h 192.168.47.75 -p 6380 SCAN ${key_num} match ${line}\* count 1000|awk 'NR==1{print $0}')
key_name=$(redis-cli -h 192.168.47.75 -p 6380 SCAN ${key_num} match ${line}\* count 1000|awk 'NR>1{print $0}')
echo ${key_name}|xargs -n 1 >> key_name.log
((key_num=scan_num))
if [ ${key_num} == 0 ]
then
break
fi
done
done
分类: redis
8.数据量有多大
10-30G
30-50G
9.服务器啥配置
cpu E5-志强处理器 6 8 12 核
内存 32G 48G 64G 128G
硬盘 500G SSD 不做RAID
网卡 1000M
10.数据持久化你们怎么做的
方案1: 2块SSD 挂载2个分区 AOF和RDB都打开 分别存在不同的硬盘里
方案2: 1块SSD AOF RDB每天备份
方案3: 1块SSD RDB 参数触发
11.redis故障
持久化没配触发条件,导致shutdown不会自动保存数据
主从复制写反了,导致清空了数据
内存满了,处理了redis处理的机制,默认是什么都不做. 添加最大内存限制参数
集群数据迁移的时候意外中断,导致槽位状态不正确,恢复有问题的槽位状态,尝试用fix工具修复,删除有问题的槽,重新分配
防火墙没开启+10000的端口,导致集群发现不了.开启防火墙
Key过期被覆盖,导致优惠券不过期 监控需要过期的key
redis集群主从复制,本机从节点复制本机主节点,整台服务器挂了,导致集群失败
12.redis运维工具
数据迁移
分析key大小
快速搭建集群
二、Memcache与Redis的区别?
1.存储方式
#Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。
Redis有部份存在硬盘上，这样能保证数据的持久性。
不过Memcache还可以缓存其他东西，图片视频等。
2.数据支持类型
#Memcache对数据类型支持相对简单,只支持k-v结构。
Redis有复杂的数据类型支持五种数据类型：字符串，列表，哈希，集合，有序集合。。
3.使用底层模型不同
#它们之间底层实现方式以及与客户端之间通信的应用协议不一样。
Redis直接自己构建了VM机制
因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
4.value大小
#Redis最大可以达到1GB，而Memcache只有1MB
5.数据恢复
#Memcache挂掉后，数据不可恢复，Redis数据丢失后可以通过AOF日志恢复。
6.应用场景不同
#Redis除啦作为数据库使用之外，还能做消息队列，数据堆栈和数据缓存等，Memcache适用于缓存sql语句，数据集，用户临时性数据，延迟查询数据 session等。
使用场景
#1、如果有持久方面的需求或对数据类型和处理有要求的应该选择redis。
2、如果简单的key/value 存储应该选择memcached。
在电子商务类的网站中，一般都有分类，然后还有搜索结果列表。针对这种情况下，我们对分类的数据，可以使用Memcached，因为分类数据一般不会改变，读多写少，直接存储在memcached中，每次查询都只需要从memcached中获取就可以了。
三、Mongo
1.MongoDB简介
Mongodb由C++语言编写的，是一个基于分布式文件存储的开源数据库系统。
是专为可扩展性，高性能和高可用性而设计的数据库， 是非关系型数据库中功能最丰富，最像关系型数据库的，它支持的数据结构非常散，是类似 json 的 bjson 格式，因此可以存储比较复杂的数据类型。
2.MongoDB特点
1.高性能：
Mongodb提供高性能的数据持久性
尤其是支持嵌入式数据模型减少数据库系统上的I/O操作
索引支持能快的查询，并且可以包括来嵌入式文档和数组中的键
2.丰富的语言查询：
Mongodb支持丰富的查询语言来支持读写操作（CRUD）以及数据汇总，文本搜索和地理空间索引
3.高可用性：
Mongodb的复制工具，成为副本集，提供自动故障转移和数据冗余，
4.水平可扩展性：
Mongodb提供了可扩展性，作为其核心功能的一部分，分片是将数据分，在一组计算机上。
5.支持多种存储引擎：
WiredTiger存储引擎和、MMAPv1存储引擎和InMemory存储引擎
3.mongo应用场景
游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的形式存储，方便查询、更新
物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内嵌数组的形式来存储，一次查询就能将订单所有的变更读取出来。
社交场景，使用 MongoDB 存储存储用户信息，以及用户发表的朋友圈信息，通过地理位置索引实现附近的人、地点等功能
物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息，并对这些信息进行多维度的分析
视频直播，使用 MongoDB 存储用户信息、礼物信息等
电商场景，使用 MongoDB
商城上衣和裤子两种商品，除了有共同属性，如产地、价格、材质、颜色等外，还有各自有不同的属性集，如上衣的独有属性是肩宽、胸围、袖长等，裤子的独有属性是臀围、脚口和裤长等
4.查看副本集状态
查看副本集状态
rs.slaveOk() #让副本可以读
rs.status() #查看副本集详细状态
rs.isMaster() #查看当前的主节点是谁
rs.printReplicationInfo() #oplog记录信息
rs.printSlaveReplicationInfo() #查看复制延迟信息
rs.config() #打印当前副本集的配置信息
1.有了副本集，为什么还需要分片？
副本集资源利用率不高
分片可以提高资源利用率
2.分片的缺点
理想情况下需要机器比较多
配置和运维变得复杂且困难
提前规划好特别重要，一旦建立后在想改变架构变得很困难
四、ES
1. Elasticsearch应用场景
1.搜索: 电商,百科,app搜索
2.高亮显示: github
3.分析和数据挖掘: ELK
2. Elasticsearch特点
1.高性能,天然分布式
2.对运维友好,不需要会java语言,开箱即用
3.功能丰富
3.es交互方式
三种交互方式
curl命令：
最繁琐
最复杂
最容易出错
不需要安装任何软件，只需要有curl命令
es-head插件:
查看数据方便
操作相对容易
需要node环境
kibana:
查看数据以及报表格式丰富
操作很简单
需要java环境和安装配置kibana
4.集群的相关名词
1.集群健康状态
绿色: 所有数据都完整,并且副本数满足
黄色: 所有数据都完整,但是有的索引副本数不满足
红色: 有的数据不完整
2.节点类型
主节点: 负责调度数据分配到哪个节点
数据节点: 负责处理落到自己身上的数据
默认: 主节点同时也是数据节点
3.数据分片
主分片: 实际存储的数据,负责读写,粗框的是主分片
副本分片: 主分片的副本,提供读,同步主分片,细框的是副本分片
4.副本:
主分片的备份,副本数量可以自定义
5.集群注意事项
集群配置文件
1同一个集群的所有成员,集群名称要一样
2.节点名称每个主机都不一样
3.选举相关参数,所有可能成为master的节点数/2+1=集群的大多数
注意1:发现节点参数不需要把集群内所有的机器IP都加上
只需要包含集群内任意一个IP和自己的IP就可以
discovery.zen.ping.unicast.hosts: ["10.0.0.51","10.0.0.53"]
注意2: 集群选举相关的参数需要设置为集群节点数的大多数
discovery.zen.minimum_master_nodes: 2
注意3: 默认创建索引为1副本5分片
注意4: 数据分配的时候会出现2中颜色
紫色: 正在迁移
黄色: 正在复制
绿色: 正常
注意5: 3节点的时候
0副本一台都不能坏
1副本的极限情况下可以坏2台: 1台1台的坏,不能同时坏2台
2副本的情况,发现节点数为1,可以同时坏2台
注意6:集群指令可以在集群内任意一个节点执行
通讯端口防火请要放行
9200 9300
监控状态不能只监控颜色(稳定状态下,监控颜色和节点数)
6.监控
监控注意,不能只监控集群状态
1.监控节点数
2.监控集群状态
3.2者任意一个发生改变了都报警
7.热更新中文分词库
五、Mysql
1.索引类型
1)BTREE:B+树索引 （Btree B+tree B*tree）
2)HASH：HASH索引 hash key
3)FULLTEXT：全文索引
4)RTREE：R树索引
2.mysql存储引擎
1.InnoDB
2.MyISAM
3.innodb核心特性
MVCC多版本并发控制
事务
行级锁
热备份
Crash Safe Recovery（自动故障恢复）
4.事务的特性
A原子性(把所有的SQL语句都视为一个单元，要么全部成功，要么全部取消)
C：一致性(交易前总和和交易后总和是一致的)
I：隔离性（事务之间不会被其他事务所影响)
D：持久性（只要提交了，永远不会被反弹）
5.备份方式
1.逻辑备份
binlog，mysqldump, into outfile,replication,mysqlbinlog
2.物理备份
cp data
xtrabackup
6.备份策略
1.全量备份
2.增量备份
3.差异备份
7.主从复制原理
主从复制的前提
1）两台或两台以上的数据库实例
2）主库要开启二进制日志
3）主库要有复制用户
4）主库的server_id和从库不同
5）从库需要在开启复制功能前，要获取到主库之前的数据（主库备份，并且记录binlog当时位置）
6）从库在第一次开启主从复制时，时必须获知主库：ip，port，user，password，logfile，pos
IP：10.0.0.51
Port：3306
User：rep
Password：oldboy123
logFile：mysql-bin.000002
Pos：120
7）从库要开启相关线程：IO、SQL
8）从库需要记录复制相关用户信息，还应该记录到上次已经从主库请求到哪个二进制日志
9）从库请求过来的binlog，首先要存下来，并且执行binlog，执行过的信息保存下来
主从复制涉及到的文件和线程
主库：
1）主库binlog：记录主库发生过的修改事件
2）dump thread：给从库传送（TP）二进制日志线程
从库：
1）relay-log（中继日志）：存储所有主库TP过来的binlog事件
2）master.info：存储复制用户信息，上次请求到的主库binlog位置点
3）IO thread：接收主库发来的binlog日志，也是从库请求主库的线程
4）SQL thread：执行主库TP过来的日志
原理
1.主库开启server_id 和bin_log 日志，以及要创建一个主从复制的用户
2.通过change master to 语句告诉从库 主库的ip ,user,password file,postion
3.从库通过start slave 命令开启复制必要的IO线程和SQL线程
4.从库通过IO线程和SQL线程 通过change master to 用户的密码相关的信息，连接主库，并验证合法性
4.从库连接成功后，会根据bing_log里的postion 信息，对比主库有没有比这个更新的数据
6.主库接收从库的请求后，会笔记bin_log的信息，如果有就会通过dump线程给从库IO 线程
7.从库通过I/O线程接收到主库发来的bin-log事件，会存储到TCP/IO的缓存中，然后返回ACK更新master.info
8.然后TCP/IP会将缓存的内容存到relay-log中
9.SQL线程会读取relay-log.info,读取到上一次执行过的为relay-log的位置点，然后继续执行后续的relay-log日志，执行完成后，更新relay-log.info
8.过滤复制
主库：
白名单:只记录白名单中列出的库的二进制日志
binlog-do-db
黑名单：不记录黑名单列出的库的二进制日志
binlog-ignore-db
从库：
白名单：只执行白名单中列出的库或者表的中继日志
--replicate-do-db=test
--replicate-do-table=test.t1
--replicate-wild-do-table=test.t2
黑名单：不执行黑名单中列出的库或者表的中继日志
--replicate-ignore-db
--replicate-ignore-table
--replicate-wild-ignore-table
9.mha高可用的原理
1)把宕机的master二进制日志保存下来。
2)找到binlog位置点最新的slave。
3)在binlog位置点最新的slave上用relay log（差异日志）修复其它slave。
4)将宕机的master上保存下来的二进制日志恢复到含有最新位置点的slave上。
5)将含有最新位置点binlog所在的slave提升为master。
6)将其它slave重新指向新提升的master，并开启主从复制。
心跳没了 3次检测 每次2秒 选主 日志补全 切换主从
10.mha 的优点
MHA优点总结
1）自动故障转移快
2）主库崩溃不存在数据一致性问题
3）不需要对当前mysql环境做重大修改
4）不需要添加额外的服务器(仅一台manager就可管理上百个replication)
5）性能优秀，可工作在半同步复制和异步复制，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。
6）只要replication支持的存储引擎，MHA都支持，不会局限于innodb
11.MySQL中间件Atlas
Atlas简介
Atlas是由 Qihoo 360公司Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它在MySQL官方推出的MySQL-Proxy 0.8.2版本的基础上，修改了大量bug，添加了很多功能特性。它在MySQL官方推出的MySQL-Proxy 0.8.2版本的基础上，修改了大量bug，添加了很多功能特性。
Atlas主要功能
1.读写分离
2.从库负载均衡
3.IP过滤
4.自动分表
5.DBA可平滑上下线DB
6.自动摘除宕机的DB
Atlas相对于官方MySQL-Proxy的优势
1.将主流程中所有Lua代码用C重写，Lua仅用于管理接口
2.重写网络模型、线程模型
3.实现了真正意义上的连接池
4.优化了锁机制，性能提高数十倍
12.atlas切换ip脚本
[root@db03 ~]# vim atlas.sh
#!/bin/bash
down_master=`sed -rn 's#^Master (.*)\(.*down!$#\1#gp' /etc/mha/manager.log`
new_master=`sed -rn 's#^Selected (.*)\(.*master.$#\1#gp' /etc/mha/manager.log`
new_master_id=`mysql -uuser -ppwd -h127.0.0.1 -P2345 -e 'select * from backends'|grep $new_master|awk '{print $1}'`
#删除被提升为主库的从库
mysql -uuser -ppwd -h127.0.0.1 -P2345 -e 'remove backend $new_master_id;save config;'
#将down掉的master变成从库
mysql -uuser -ppwd -h127.0.0.1 -P2345 -e 'add slave ${down_master}:3306;save config;'
/usr/local/mysql-proxy/bin/mysql-proxyd test restart
