多线程高并发(下)

集群的高并发技术总结

集群内高并发

  • 集群的高并发技术总结
  • 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结构;同步,临时节点;统一命名。

你可能感兴趣的:(集群,数据库,队列,分布式,redis,java)