多线程高并发（下）
集群的高并发技术总结
集群内高并发
- 集群的高并发技术总结
- Redis（三个模式不能作为数据库用，通过AKF一变多）
-
- 硬盘慢
-
- 寻址
- 带宽
- 数据在内存和磁盘体积不一样
- 二进制安全
-
- 字节流
- 字符流
- value
-
- string（Byte）
-
- 字符
- 数值
-
- incr
- bitmaps
-
- 用户某天到某天 登录数
- 618准备礼物数
-
- bitop or bitcount
- encoding
-
- int string row
- row 编码格式化
- hash
-
- 对字段进行数值运算
- 点赞，收藏，详情页
- set
-
- 去重，排序
- sinter
-
- 交集
- sinterstore
- sdif
-
- 差集
- sunion
-
- 并集
- spop
-
- 年会抽奖
- srandmember key count正数代表去重，负数代表不去重
-
- 取名
- list
-
- 栈，队列，数组，单播队列
- sorted set
-
- zrange
- zunion
- 排序是怎么实现的
-
- skip list 跳表
- memcached
-
- value没有类型概念
- epoll 用户空间和内核空间有个共享区域mmap，红黑树，链表
- kernel的epoll是同步的，非阻塞多路复用
- 管道
-
- 使用nc建立socket连接
- 发布订阅
-
- 直播
- 历史数据存sorted list或者 db
- 事务
-
- MULTI
- exec 执行
- watch 值被修改了 开启事务后的所有命令失败
- 布隆过滤器
-
- bloom
- counting bloom
- cukcoo 布谷鸟
- 击穿了，添加个key
- 只能增加，不能删除
- redis作为数据库和缓存的区别
-
- 只保留热数据，内存大小有限
- 缓存数据不重要，不是全量数据
- 缓存应该随着访问变化，热数据
- 业务运转
-
- 内存是有限，随着访问的变化，应该淘汰掉冷数据
- 内存多大 maxmemory maxmemory-policy noevition LFU碰了多少次 LRU多久没碰他
- 持久化
-
- RDB
-
- 时间性
- save
- bgsave
-
- fork创建子进程
- 配置文件中bgsave这个规则：save这个标识
- 弊端
-
- 不支持拉链
- 永远只有一个rdb文件
- 丢失数据相对多一些，时点与时点之间窗口数据容易丢失，8点得到一个rdb，9点要落一个rdb，挂机了
- 优点
-
- 类似于java中的序列化，恢复速度很快
- AOF
-
- 写数据记录到文件中，丢失数据少
- 如果同时开启了RDB和AOF，但是数据恢复只会用AOF
- 缺点
-
- 无限大，恢复数据慢
- 4.0以前
-
- 重写
-
- 删除抵消，合并重复
- 4.0以后
-
- 重写
-
- 将老的数据RDB到aof文件中，将增量以指令的形式append到aof（aof是一个混合体，利用了rdb的快，也利用了日志全量）
- aof文件前有个“redis”
- IO级别
-
- no
- always
- everysec，默认
- 进程是数据隔离的
-
- 父进程的修改不会影响子进程
- 子进程的修改也不会影响父进程
- fork（内核）
-
- 写时复制，内核机制
- 创建子进程并不发生复制
- 子进程写
- CAP
-
- 一部分给出ok，另一部分不算数
-
- 网络分区，脑裂
-
- 分区容忍性
- 一致性
- 可用性
- 分区容错性
- P是绝对不可能丢失，一般是CP，AP
-
- CP (hbase，银行)
- AP(eureka,zookeeper)
- 单机，单节点，单实例
-
- 单机故障
- 存储有限
- 压力
- 主从
-
- flushing old data ；load DB in memory
- repliica-serve-state-data yes 允许查
- replica-read-only yes
- repl-diskless-sync no 走磁盘
- repl-backlog-size 1mb 增量复制 超过了触发全量
- 哨兵
-
- 哨兵间怎么互相知道（发布订阅 PSUBSCRIBE）
- 无法解决容量问题
-
- 永远是从节点复制主节点数据
- 不是主从每个分点
- 客户端连接哨兵 .master().sentinel()
- 不是绝对的实时同步（RDB AOF）
- 可能连最终一致性都算不上
-
- 主的数据还没发完就挂了
- 集群模式
-
- 1、random
- 2、module
- 3、kemata：一致性hash，data node参与计算，hash环
-
- 优点：加节点的确可以分担其他节点的压力，不会造成全局洗牌；缺点：新增节点造成一小部分数据不能命中.1问题，击穿到mysql；2方案，每次去取离我最近的2个物理节点。更倾向于作为缓存而不是数据库
- 虚拟节点
-
- 解决数据倾斜
- 数据分治
-
- 数据不分开就一定发生事务
- 聚合操作很难实现事务
- hash tag
-
- 有些操作需要依赖多个key
- git clone 失败 yum update nss
- twemproxy
- predixy
- 集群
-
- utils create-cluster
-
- ./create-cluster start
- ./create-cluster create
- {oo}k1
- cluster-enabled yes
- redis-cli-cluster reshard 127.0.0.1:30001
- redis-cli-cluster info 127.0.0.1:30001
- redis-cli-cluser check 127.0.0.1:30001
- 击穿
-
- 1发生了高并发 2key的过期或没有key造成并发访问数据库
-
- 解决方法1get key 2 setnx 3.1 TRUE->去数据库 3.2false->1
-
- 如果一个人挂了-》分布式锁，设置锁的过期时间。如果没挂但超时了-》多线程1个线程取库 2一个线程监控是否取回来，更新锁时间
- 穿透
-
- 数据库里根本没有
-
- 布隆过滤器
-
- client处理
- client：算法；redis：bitmap 无状态；redis集成布隆
- 雪崩
-
- 大量的key同时失效，类似于击穿，大量访问到达数据库
-
- 时点性无关,随机设置过期时间
- 零点
-
- 业务层加判断，零点超时
- 强依赖击穿方案
- 分布式锁
-
- setnx
- 过期时间
- 多线程解决延迟过期
- redission 更好
- zk 更更好
- 7层
-
- 协议就是规范标准
- 哪7层
-
- 应用层
-
- TCP(面向连接的可靠性协议)
- udp
- icmp
- dchp
- http
- https
- ssh
- 表示层
- 会话层
- 传输控制协议（从这开始往下进入内核）
-
- 三次握手
- 第三次握手会连接，带着数据包加确认包
- 网络层（找下一跳）
- 数据链路层
- 物理层
- 三次握手，四次分手（最小粒度，不可被分割）
- route-u
- arp-a
- 负载服务器
-
- nigix会跟请求方握手，然后拆开7层，看到url，然后再根据url请求不同的tomcat，这个4层（后四层）不会握手，看url只看ip
- 一层LVS+一层nginx
- LVS
-
- NAT
-
- 地址替换
- 基于3-4层
- DR
-
- 基于2层
- mac地址欺骗
- 速度快，成本低
- TUN
- 接口配置
-
- netmask ifcfg eth0:2 192.168.150.100/24
- ifcfg eth0:2 down
- /proc/sys/net/ipv4/conf （eth0、all） -- echo 1>arp_igore，ecto 2>arp_announce
- 内环接口
-
- ifcfg lo：2 192.168.150.100 netmask 255.255.255.255
- 内核级
- 调了发给自己
- Nginx
- 七层
- 有几个核心起几个线程
-
- vi指令
-
- O向上开一行
- D删除后面的所有
- 光标移到要改的位置 r 3 火把原来的字符改为3
- LVS数据同步少
- Zookeeper
Redis（三个模式不能作为数据库用，通过AKF一变多）
硬盘慢
寻址
带宽
数据在内存和磁盘体积不一样
二进制安全
字节流
字符流
value
string（Byte）
字符
数值
incr
bitmaps
用户某天到某天 登录数
618准备礼物数
bitop or bitcount
encoding
int string row
row 编码格式化
hash
对字段进行数值运算
点赞，收藏，详情页
set
去重，排序
sinter
交集
sinterstore
sdif
差集
sunion
并集
spop
年会抽奖
srandmember key count正数代表去重，负数代表不去重
取名
list
栈，队列，数组，单播队列
sorted set
zrange
zunion
排序是怎么实现的
skip list 跳表
memcached
value没有类型概念
epoll 用户空间和内核空间有个共享区域mmap，红黑树，链表
kernel的epoll是同步的，非阻塞多路复用
管道
使用nc建立socket连接
发布订阅
直播
历史数据存sorted list或者 db
事务
MULTI
exec 执行
watch 值被修改了 开启事务后的所有命令失败
布隆过滤器
bloom
counting bloom
cukcoo 布谷鸟
击穿了，添加个key
只能增加，不能删除
redis作为数据库和缓存的区别
只保留热数据，内存大小有限
缓存数据不重要，不是全量数据
缓存应该随着访问变化，热数据
业务运转
内存是有限，随着访问的变化，应该淘汰掉冷数据
内存多大 maxmemory maxmemory-policy noevition LFU碰了多少次 LRU多久没碰他
持久化
RDB
时间性
save
bgsave
fork创建子进程
配置文件中bgsave这个规则：save这个标识
弊端
不支持拉链
永远只有一个rdb文件
丢失数据相对多一些，时点与时点之间窗口数据容易丢失，8点得到一个rdb，9点要落一个rdb，挂机了
优点
类似于java中的序列化，恢复速度很快
AOF
写数据记录到文件中，丢失数据少
如果同时开启了RDB和AOF，但是数据恢复只会用AOF
缺点
无限大，恢复数据慢
4.0以前
重写
删除抵消，合并重复
4.0以后
重写
将老的数据RDB到aof文件中，将增量以指令的形式append到aof（aof是一个混合体，利用了rdb的快，也利用了日志全量）
aof文件前有个“redis”
IO级别
no
always
everysec，默认
进程是数据隔离的
父进程的修改不会影响子进程
子进程的修改也不会影响父进程
fork（内核）
写时复制，内核机制
创建子进程并不发生复制
子进程写
CAP
一部分给出ok，另一部分不算数
网络分区，脑裂
分区容忍性
一致性
可用性
分区容错性
P是绝对不可能丢失，一般是CP，AP
CP (hbase，银行)
AP(eureka,zookeeper)
单机，单节点，单实例
单机故障
存储有限
压力
主从
flushing old data ；load DB in memory
repliica-serve-state-data yes 允许查
replica-read-only yes
repl-diskless-sync no 走磁盘
repl-backlog-size 1mb 增量复制 超过了触发全量
哨兵
哨兵间怎么互相知道（发布订阅 PSUBSCRIBE）
无法解决容量问题
永远是从节点复制主节点数据
不是主从每个分点
客户端连接哨兵 .master().sentinel()
不是绝对的实时同步（RDB AOF）
可能连最终一致性都算不上
主的数据还没发完就挂了
集群模式
1、random
2、module
3、kemata：一致性hash，data node参与计算，hash环
优点：加节点的确可以分担其他节点的压力，不会造成全局洗牌；缺点：新增节点造成一小部分数据不能命中.1问题，击穿到mysql；2方案，每次去取离我最近的2个物理节点。更倾向于作为缓存而不是数据库
虚拟节点
解决数据倾斜
数据分治
数据不分开就一定发生事务
聚合操作很难实现事务
hash tag
有些操作需要依赖多个key
git clone 失败 yum update nss
twemproxy
predixy
集群
utils create-cluster
./create-cluster start
./create-cluster create
{oo}k1
cluster-enabled yes
redis-cli-cluster reshard 127.0.0.1:30001
redis-cli-cluster info 127.0.0.1:30001
redis-cli-cluser check 127.0.0.1:30001
击穿
1发生了高并发 2key的过期或没有key造成并发访问数据库
解决方法1get key 2 setnx 3.1 TRUE->去数据库 3.2false->1
如果一个人挂了-》分布式锁，设置锁的过期时间。如果没挂但超时了-》多线程1个线程取库 2一个线程监控是否取回来，更新锁时间
穿透
数据库里根本没有
布隆过滤器
client处理
client：算法；redis：bitmap 无状态；redis集成布隆
雪崩
大量的key同时失效，类似于击穿，大量访问到达数据库
时点性无关,随机设置过期时间
零点
业务层加判断，零点超时
强依赖击穿方案
分布式锁
setnx
过期时间
多线程解决延迟过期
redission 更好
zk 更更好
7层
协议就是规范标准
哪7层
应用层
TCP(面向连接的可靠性协议)
udp
icmp
dchp
http
https
ssh
表示层
会话层
传输控制协议（从这开始往下进入内核）
三次握手
第三次握手会连接，带着数据包加确认包
网络层（找下一跳）
数据链路层
物理层
三次握手，四次分手（最小粒度，不可被分割）
route-u
arp-a
负载服务器
nigix会跟请求方握手，然后拆开7层，看到url，然后再根据url请求不同的tomcat，这个4层（后四层）不会握手，看url只看ip
一层LVS+一层nginx
LVS
NAT
地址替换
基于3-4层
DR
基于2层
mac地址欺骗
速度快，成本低
TUN
接口配置
netmask ifcfg eth0:2 192.168.150.100/24
ifcfg eth0:2 down
/proc/sys/net/ipv4/conf （eth0、all） – echo 1>arp_igore，ecto 2>arp_announce
内环接口
ifcfg lo：2 192.168.150.100 netmask 255.255.255.255
内核级
调了发给自己
Nginx
七层
有几个核心起几个线程
vi指令
O向上开一行
D删除后面的所有
光标移到要改的位置 r 3 火把原来的字符改为3
LVS数据同步少
Zookeeper
特性：数据在内存；性能高；复制集群；顺序性；更新原子性；可靠及时：快速恢复。对外：数据可靠 可用 一致性。
端口说明：2888,3888.最初3888选择leader；选出了leader后，leader开2888通信，session也会广播。两个操作之间差2.pZxid是最后一个被操作节点的事务ID。高32leader纪元，低32事务id。observer放大查询能力。只有follow才能选举。
作用：统一配置管理–1M数据；分组管理path结构；同步，临时节点；统一命名。