慢查询、pipline、发布订阅、 bitmap位图、 hyperloglog、geo、持久化、主从、哨兵

【慢查询】

# 1 我们配置一个时间，如果查询时间超过了我们设置的时间，我们就认为这是一个慢查询
# 2 慢查询是一个先进先出的队列,固定长度,保存在内存中--->通过设置慢查询，以后超过我们设置时间的命令，就会放在这个队列中
# 3 后期我们通过查询这个队列，过滤出 慢命令--》优化慢命令


# 4 实操：
    1 配置慢查询
    # 设置记录所有命令
    config set slowlog-log-slower-than 0
    # 最多记录100条
    config set slowlog-max-len 100
    # 持久化到本地配置文件
    config rewrite
    
    2 查看慢查询队列
    slowlog get [n]  #获取慢查询队列
        '''
        日志由4个属性组成：
        1）日志的标识id
        2）发生的时间戳
        3）命令耗时
        4）执行的命令和参数
        '''
     slowlog len #获取慢查询队列长度
    slowlog reset #清空慢查询队列
    
    
# mysql ： slow_query_log

。

。

【pipline命令管道】

#1 Redis的pipeline(管道)功能在命令行中没有，但redis是支持pipeline的，而且在各个语言版的client中都有相应的实现

# 2 pipeline期间将“独占”链接，多个命令，放到一个pipline(管道中)，要么都执行，要么都不执行

# 3 python中使用pipline
import redis

pool = redis.ConnectionPool(host='192.168.241.129', port=6379, password='jh123')
conn = redis.Redis(connection_pool=pool)
# pipe = r.pipeline(transaction=False)
# 创建pipeline
pipe =conn.pipeline(transaction=True)
# 开启事务
pipe.multi()

pipe.set('name', 'jh')
# 其他代码，可能出异常
pipe.set('role', 'nb')

pipe.execute()


# 4 事务四大特性
    -原子性
    -持久性
    -一致性
    -隔离性
# 6 redis有没有事务，能不能有这四大特性？
    -因为redis，能实现事务的四大特性---》咱们说它支持
    -通过pipline实现原子性--》通过pipline可以实现事务
    -pipline只支持单实例，集群环境，不支持---》集群环境不支持事务
    
    
# 7 原生操作，实现乐观锁

# 7.1 mutil  开启事务，放到管道中一次性执行
multi   # 开启事务
set name xxxx
set age 18
exec ,然后再去查，就发现数据改了


# 7.2 模拟事务回顾 ，乐观锁
# 在开启事务之前，先watch
watch age
multi
decr age
exec

# 另一台机器
multi
decr age
exec  # 先执行，上面的执行就会失败(乐观锁，被wathc的事务不会执行成功)



# 7.3 使用redis实现乐观锁


## 利用redis的乐观锁，实现秒杀系统的数据同步（基于watch实现），
## 用户1 
import redis
conn = redis.Redis(host='192.168.241.129',port=6379)
with conn.pipeline() as pipe:
    # 先监视，自己的值没有被修改过
    conn.watch('count')
    # 事务开始
    pipe.multi()
    old_count = conn.get('count')
    count = int(old_count)
    input('我考虑一下')
    if count > 0:  # 有库存
        pipe.set('count', count - 1)

    # 执行，把所有命令一次性推送过去
    ret = pipe.execute()
    print(type(ret))
    print(ret)
## 用户2
import redis
conn = redis.Redis(host='127.0.0.1',port=6379)
with conn.pipeline() as pipe:
    # 先监视，自己的值没有被修改过
    conn.watch('count')
    # 事务开始
    pipe.multi()
    old_count = conn.get('count')
    count = int(old_count)
    if count > 0:  # 有库存
        pipe.set('count', count - 1)
    # 执行，把所有命令一次性推送过去
    ret=pipe.execute()
    print(type(ret))

# 注：windows下如果数据被修改了，不会抛异常，只是返回结果的列表为空，mac和linux会直接抛异常

# 秒杀系统核心逻辑测试，创建100个线程并发秒杀（代码有问题）
import redis
from threading import Thread
def choose(name, conn):
    with conn.pipeline() as pipe:
        # 先监视，自己的值没有被修改过
        conn.watch('count')
        # 事务开始
        pipe.multi()
        old_count = conn.get('count')
        count = int(old_count)
        # input('我考虑一下')
        # time.sleep(random.randint(1, 2))
        if count > 0:  # 有库存
            pipe.set('count', count - 1)

        # 执行，把所有命令一次性推送过去
        ret = pipe.execute()
        print(ret)
        if len(ret) > 0:
            print('第%s个人抢购成功' % name)
        else:
            print('第%s个人抢购失败' % name)


if __name__ == '__main__':
    conn = redis.Redis(host='192.168.241.129', port=6379)
    for i in range(100):

        t = Thread(target=choose, args=(i, conn))
        t.start()

。

。

【发布订 1 # 发布订阅(观察者模式)：发布者发布了消息，所有的订阅者都可以收到，就是生产者消费者模型

    -生产者消费者 发布订阅模型
    -生产者消费者 队列
    
# 原生实现
    -发布消息：
        publish channel message 
    -订阅（现有订阅者，然后发布者才有消息）
        subscribe channel
    -接收消息
        -只要发布者一发布，订阅者都会受到
        
        
# python+redis实现
import redis
# 连接到Redis服务器
r = redis.Redis(host='localhost', port=6379, db=0)
# 发布者
20 r.publish('channel', 'message')
 
    
    
import redis
# 连接到Redis服务器
r = redis.Redis(host='localhost', port=6379, db=0)  
# 订阅者
sub = r.pubsub()
sub.subscribe('channel')
for message in sub.listen():
    print(message)
　　　　

if isinstance(message['data'],bytes):
print(message['data'].decode('utf-8'))
if message['data'].decode('utf-8')['type']=='下单'：
print(message['data'].decode('utf-8')['user'],'发送短信')

 。

。

【bitmap位图】

#1 本质是字符串

#2 操作比特位
  b         i        g
01100011  01101001   01100111
set hello big #放入key位hello 值为big的字符串
getbit hello 0 #取位图的第0个位置，返回0
getbit hello 1 #取位图的第1个位置，返回1 如上图

# 我们可以直接操纵位
setbit key offset value #给位图指定索引设置值
setbit hello 7 1 #把hello的第7个位置设为1 这样，big就变成了cig


# 3 独立用户统计---》统计日活---》用户量足够大--》节约内存
    -10亿用户  用户id1 2  3  10亿
    
    1个bytes--》8个比特位---》能表示多少种变化？
        2的7次方-1 ：-128 到127之间
    8个bytes--》64个比特位--》9223372036854775808
    
    如果以集合存储：存一个用户，就要8个bytes---》存1亿用户 8 bytes*1亿
    
    -统计日活，只要用户登录，就把用户id放到集合中
    -晚上只需要统计一下 集合大小---》就能统计出日活   
    -使用集合存储---》1--》32位--》1亿用户 5千万左右---》需要 200MB空间
        int8个比特位表示范围 -128--127之间
        int16 
        int32 个比特位表示范围 -2的31次方---2的31次方  2147483648
        
    -使用位图---》12.5MB空间

    
# 获取前3位中1的个数
bitcount name 0 3 

 。

。

【hyperloglog】

# 1 基于HyperLogLog算法：极小的空间完成独立数量统计,本质还是字符串

# 2 
    -放值：pfadd uuids "uuid1" "uuid2" "uuid3" "uuid4"
    -统计个数：pfcount uuids
    -判断一个值是否在里面：pfadd uuids "uuid1"（返回1/0）
      
# 3 统计日活用户

# 4 去重：爬过的网址，就不爬了--》存一下爬过的
'www.baidu.com'--->放到 pfadd 中--》返回1，说明没爬过--》继续爬取--》如果返回0，不爬了

# 5 黑白名单

# 6 注意
百万级别独立用户统计，百万条数据只占15k
错误率 0.81%
无法取出单条数据，只能统计个数

# 7 类似于布隆过滤器，算法不一样

。

。

【geo】

# 1 geo 地理位置信息
GEO（地理信息定位）：存储经纬度，计算两地距离，范围等
北京：116.28，39.55
天津：117.12，39.08
可以计算天津到北京的距离，天津周围50km的城市，外卖等

# 2 经纬度哪里来？
    - web端：js获取--》掉接口，传给后端
    - 安卓，ios端：线程的代码
    -微信小程序
          
# 3 js获取经纬度
if (navigator.geolocation) {
  navigator.geolocation.getCurrentPosition(function(position) {
    var latitude = position.coords.latitude;
    var longitude = position.coords.longitude;
    console.log("经度：" + longitude);
    console.log("纬度：" + latitude);
  });
} else {
  console.log("浏览器不支持Geolocation API");
}


# 4 增加地理位置信息
geoadd key longitude latitude member #增加地理位置信息

geoadd cities:locations 116.28 39.55 beijing #把北京地理信息天津到cities:locations中
geoadd cities:locations 117.12 39.08 tianjin
geoadd cities:locations 114.29 38.02 shijiazhuang
geoadd cities:locations 118.01 39.38 tangshan
geoadd cities:locations 115.29 38.51 baoding


# 5 获取天津的经纬度  geopos key member #获取地理位置信息
geopos cities:locations tianjin
# 根据经纬度--》文字
from geopy.geocoders import Nominatim
geolocator = Nominatim(user_agent="my_application")
def geolocate_point(latitude, longitude):
    location = geolocator.reverse(f"{latitude}, {longitude}")
    return location.address
# 示例使用经纬度
latitude = 39.983424
longitude = 116.307224
address = geolocate_point(latitude, longitude)
print(address)

# 6 统计两个地理位置之间的距离
geodist cities:locations beijing tianjin km #北京到天津的距离，89公里

# 7 统计某个地理位置方圆xx公里，有xx
georadiusbymember cities:locations beijing 150 km

。

。

【持久化】

# 1 什么是持久化
redis的所有数据保存在内存中，对数据的更新将异步的保存到硬盘上

# 2 持久化的实现方式
快照：某时某刻数据的一个完成备份，
     -mysql的Dump:写一个mysql自动定时备份和清理前后端程序
    -redis的RDB：某一刻，把内存中得数据，保存到硬盘上这个操作就是rbd的持久化
写日志：任何操作记录日志，要恢复数据，只要把日志重新走一遍即可
    -mysql的 Binlog
    -Redis的 AOF
    
# 3 redis有三种持久化方案
    -rdb：快照
    -aof：日志
    -混合持久化：rdb+aof混合方案

。

rdb

# 4 rdb方案 ：三种方式
    1 人工同步：客户端 ： save  # 同步操作，会阻塞其他命令--》单线程架构
    2 人工异步：客户端：bgsave  # 异步操作，不会阻塞其他命令
    3 配置文件
        save 900 1 #配置一条
        save 300 10 #配置一条
        save 60 10000 #配置一条

        save 60 5

# 5 最佳配置
#最佳配置
save 900 1 
save 300 10 
save 60 10000 
dbfilename dump-6379.rdb  #以端口号作为文件名，可能一台机器上很多reids，不会乱
dir ./bigdiskpath #保存路径放到一个大硬盘位置目录
stop-writes-on-bgsave-error yes #出现错误停止
rdbcompression yes #压缩
rdbchecksum yes #校验


# 6 确定 RDB问题
    耗时，耗性能：
    不可控，可能会丢失数据

# redis 持久化方案
    -rdb：快照方案
        -save
        -bgsave
        -配置文件  save 时间 条数
        
        -xx.rdb 文件---》下次启动redis-server--》自动加载rdb到内存中
        
        -lastsave  ：查看最后执行持久化的时间戳
        
        -stop-writes-on-bgsave-error：当磁盘满时，是否关闭redis的写操作
        
    -aof：日志方案(删除，新增，修改)
        -自动记录日志
        -xx.aof 文件
        -aof策略
            -always：redis–》写命令刷新的缓冲区—》每条命令fsync到硬盘—》AOF文件
            -everysec（默认值）：redis——》写命令刷新的缓冲区—》每秒把缓冲区fsync到硬盘–》AOF文件
            -no:redis——》写命令刷新的缓冲区—》操作系统决定，缓冲区fsync到硬盘–》AOF文件
        -配置文件：
            appendonly yes #将该选项设置为yes，打开
            appendfilename "appendonly.aof" #文件保存的名字
            appendfsync everysec #采用第二种策略
            no-appendfsync-on-rewrite yes
                   
    -两种方案同时用？
        -没有任何问题
        -其实 RDB 和 AOF 两种方式也可以同时使用，在这种情况下，如果 redis 重启的话，则会优先采用 AOF 方式来进行数据恢复，这是因为 AOF 方式的数据恢复完整度更高

 

。

aof

# 1 客户端每写入一条命令，都记录一条日志，放到日志文件中，如果出现宕机，可以将数据完全恢复
# 2 AOF的三种策略日志不是直接写到硬盘上，而是先放在缓冲区，缓冲区根据一些策略，写到硬盘上always：redis–》写命令刷新的缓冲区—》每条命令fsync到硬盘—》AOF文件everysec（默认值）：redis——》
写命令刷新的缓冲区—》每秒把缓冲区fsync到硬盘–》AOF文件no:redis——》写命令刷新的缓冲区—》操作系统决定，缓冲区fsync到硬盘–》AOF文件​
# 3 配置文件appendonly yes #将该选项设置为yes，打开appendfilename "appendonly-${port}.aof" 
#文件保存的名字appendfsync everysec 
#采用第二种策略dir /bigdiskpath 
#存放的路径no-appendfsync-on-rewrite yes​​appendonly yesappendfilename "appendonly.aof"appendfsync everysecno-appendfsync-on-rewrite yes​​

# 4 放在了文件中appendonly.aof.1.base.rdb ：永久的appendonly.aof.1.incr.aof ：临时的appendonly.aof.manifest： 哪些文件存了数据

 

（AOF重写）

一. aof重写策略解释

# 1 Redis 在长期运行的过程中，aof 文件会越变越长。如果机器宕机重启，“重演”整个 aof 文件会非常耗时，导致长时间 Redis 无法对外提供服务。因此就需要对 aof 文件做一下“瘦身”运动【把失效的或可以合并的日志合并】

# 2 为了让 aof 文件的大小控制在合理的范围内，Redis 提供了 AOF 重写机制，手动执行BGREWRITEAOF命令，开始重写 aof 文件，如下所示：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
'''
通过 bgrewriteaof 操作后，服务器会生成一个新的 aof 文件，该文件具有以下特点：

新的 aof 文件记录的数据库数据和原 aof 文件记录的数据库数据完全一致；
新的 aof 文件会使用尽可能少的命令来记录数据库数据，因此新的 aof 文件的体积会小很多；
AOF 重写期间，服务器不会被阻塞，它可以正常处理客户端发送的命令。
即使 Bgrewriteaof 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 Bgrewriteaof 成功之前不会被修改

'''

二.触发aof重写
    -手动：BGREWRITEAOF

    -自动：
    #默认配置项
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb #表示触发AOF重写的最小文件体积,大于或等于64MB自动触发。
    '''
    该配置项表示：触发重写所需要的 aof 文件体积百分比，只有当 aof 文件的增量大于 100% 时才进行重写，也就是大一倍。比如，第一次重写时文件大小为 64M，那么第二次触发重写的体积为 128M，第三次重写为 256M，以此类推。如果将百分比值设置为 0 就表示关闭 AOF 自动重写功能
    '''   
    
# 3 其他配置
'''
no-appendfsync-on-rewrite：重写时，不会执行appendfsync操作

该参数表示在正在进行AOF重写时不会将AOF缓冲区中的数据同步到旧的AOF文件磁盘，也就是说在进行AOF重写的时候，如果此时有写操作进来，此时写操作的命令会放在aof_buf缓存中（内存中），而不会将其追加到旧的AOF文件中，这么做是为了避免同时写旧的AOF文件和新的AOF文件对磁盘产生的压力。

默认是ON，表示关闭，即在AOF重写时，会对AOF缓冲区中的数据做同步磁盘操作，这在很大程度上保证了数据的安全性。但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

如果no-appendfsync-on-rewrite为yes，不写入aof文件，只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
'''

 

 

 。

。

【混合持久化（7.x默认自动开启）】

# 混合持久化原理:目的是为了加快恢复
在开启混合持久化的情况下，AOF 重写时会把 Redis 的持久化数据，以 RDB 的格式写入到 AOF 文件的开头，之后的数据再以 AOF 的格式化追加的文件的末尾

# 配置是：
appendonly yes
appendfilename "appendonly-6379.aof"
appendfsync everysec
no-appendfsync-on-rewrite yes
aof-use-rdb-preamble yes #开启了混合持久化
======================================================

# 总结：
    1 使用混合持久化
        -开启rdb，开启aof
        -aof-use-rdb-preamble yes  # 内部原理--》只要触发aof重写，会把rdb放在aof的开头
         
# aof 文件作用
     xx.manifest ： 存放了，哪些aof文件合并起来是总的【保存了所有aof合rdb文件】
     xx.2.incr.aof：存放了 aof的日志，没有rdb的二进制
     xx.aof.2.base.rdb :存放的是 rdb的二进制文件
     2 数字表示，aof重写了几次

 。

。

【主从】

# 一. 什么是主从复制
    从库复制主库的数据，保证主库和从库数据一直一致，从库只能读。
# 1.1 问题
    机器故障；容量瓶颈；QPS瓶颈
    机器故障：主从，哨兵
    容量瓶颈：集群
    QPS瓶颈：主从
# 1.2 主从架构
    一主一从，一主多从
# 1.3 作用
    做读写分离
    做数据副本
# 1.4 注意
    一个master可以有多个slave
    一个slave只能有一个master
    数据流向是单向的，从master到slave【以后slave只用来读，不用来写了】      
    
# 二. 主从复制流程
1. 副本库(从库，slave)通过slaveof 127.0.0.1 6379命令,连接主库,并发送SYNC给主库 
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从关系断开时,从库数据没有任何损坏,在下次重连之后,从库发送PSYNC给主库
9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的

# 3 主库是否要开启持久化：无所谓，为了防止数据丢失，都会开启

# 4 实操
    - 1 命令：
        #链接主从复制：在 6380的redis上执行
        slaveof 127.0.0.1 6379
        # 断开主从复制
        slaveof no one
    - 2 配置文件
slaveof 127.0.0.1 6379
slave-read-only yes
masterauth "jh123" ，这是主节点密码，如果不配置，从节点获取不到主节点的信息
    
# 5 通过info查看主从信息    
      
# 6 主从复制的辅助配置
min-slaves-to-write 2
min-slaves-max-lag 3
#那么在从服务器的数量少于2个，或者三个从服务器的延迟（lag）值都大于或等于3秒时，主服务器将拒绝执行写命令

。

 Python的主从 操作

# 1 redis.py 原生操作  自己处理
conn1=链接主库
conn2=链接从库

conn1.set('name','zzz')

print(conn2.get('name'))


# 2 django中缓存使用
CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://localhost:6379/0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
        }
    },
    "redis1": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://localhost:6379/0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
        }
    }
}
from django.core.cache import caches
caches['redis1'].set("name",'xx')  # 写
res=caches['default'].get('name')  # 读
requirepass "jh123"

### 主从复制时，如果主库有密码，从库要配置

masterauth 'jh123'

。

。

【哨兵】

##################### 1 一主两从########################################
    -在三台机器，写配置文件，启动即可(三台机器要联通)
##### ##### ##### 主库##### ##### ##### 
daemonize yes
bind 0.0.0.0
pidfile "/var/run/redis.pid"
port 6379
dir "/root/redis/data"
logfile "6379.log"
protected-mode no
requirepass "654321"
save 60 5
appendonly yes
appendfilename "appendonly-6379.aof"
appendfsync everysec
no-appendfsync-on-rewrite yes
aof-use-rdb-preamble yes
masterauth '654321'

##### ##### ##### 从库1##### ##### ##### 
daemonize yes
bind 0.0.0.0
pidfile "/var/run/redis.pid"
port 6379
dir "/root/redis/data"
logfile "6379.log"
protected-mode no
requirepass "654321"
save 60 5

appendonly yes
appendfilename "appendonly-6379.aof"
appendfsync everysec
no-appendfsync-on-rewrite yes
aof-use-rdb-preamble yes

slaveof 主库地址 6379
masterauth "654321"
slave-read-only yes


##### ##### ##### 从库2##### ##### ##### 
daemonize yes
bind 0.0.0.0
pidfile "/var/run/redis.pid"
port 6379
dir "/root/redis/data"
logfile "6379.log"
protected-mode no
requirepass "654321"
save 60 5

appendonly yes
appendfilename "appendonly-6379.aof"
appendfsync everysec
no-appendfsync-on-rewrite yes
aof-use-rdb-preamble yes

slaveof 主库地址 6379
masterauth "654321"
slave-read-only yes


######2 一主多从存在的问题###
#1 主从复制，主节点发生故障，需要做故障转移，可以手动转移：让其中一个slave变成master：哨兵
#2 主从复制，只能主写数据，所以写能力和存储能力有限：集群


#### 3 哨兵原理
可以做故障判断，故障转移，通知客户端（其实是一个进程），客户端直接连接sentinel的地址
1 多个sentinel发现并确认master有问题
2 选举触一个sentinel作为领导
3 选取一个slave作为新的master
4 通知其余slave成为新的master的slave
5 通知客户端主从变化
6 等待老的master复活成为新master的slave



## 4 搭建步骤
## 4.1 哨兵1  配置文件
port 26379
daemonize yes
dir data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel.log"

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster "654321"
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
## 4.2 哨兵2 配置文件
port 26380
daemonize yes
dir data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel.log"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster "654321"
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
## 4.2 哨兵3 配置文件
port 26381
daemonize yes
dir data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel.log"

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster "654321"
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

### 4.4 启动3个哨兵
redis-sentinel ./sentinel_26379.conf
redis-sentinel ./sentinel_26380.conf
redis-sentinel ./sentinel_26381.conf


### 4.5 链接哨兵
redis-cli -p 26379
# info 查看状态


## 4.6 停止主库
-自动切换