DEV Community: testted123456

kafka consumer

testted123456 — Wed, 28 Sep 2022 14:44:11 +0000

分配策略

range

8个partition，3个consumer：
consumer 1: partition 1、partition 2、partition 3 consumer 2: partition 4、partition 5、partition 6 consumer 3: partition 7、partition 8

round robin

consumer 1: partition 1、partition 4、partition 7 consumer 2: partition 2、partition 5、partition 8 consumer 3: partition 3、partition 6

sticky

kafka-producer

testted123456 — Tue, 13 Sep 2022 16:36:17 +0000

一、分区策略

二、ISR（in-sync replica set)：与leader同步的follower

每个partition收到消息，需要给producer发送ack。producer收到ack会继续发送下一条，否则重复发送
partition发送ack时机

leader同步follower后发送ack，这样leader挂了数据不会丢失
全部follower同步后再给producer发送ack
follower从leader同步完成后发送ack给leader，如果超时(replica.lag.time.max.ms)不发送，则被踢出ISR
leader故障，会从ISR选出leader

三、ack机制

ack参数配置（request-required-acks）：

request-required-acks:-1， follower全部同步完后leader在返回acks给producer；数据不丢失，延迟性差
request-required-acks:1， leader成功收到数据就返回acks；leader没有持久化就挂了，会丢数据
request-required-acks:0， producer不等leader返回acks就继续发送消息

幂等 enable.idempotence=true，producer初始化时会分配一个pid，发往partition的数据会带上sequence number，broker会对进行缓存，相同的数据broker只会缓存一条

四、数据一致性

kafka文件存储

testted123456 — Sun, 11 Sep 2022 15:11:38 +0000

一、kafka架构

producer：生产者。producer产生的数据追加到partition的log文件中，每条数据有自己的offset
consumer：消费者
consumer group：消费者组；对应一个partition，一个消费组中只能有一个consumer来消费
broker：一个kafka服务就是一个broker
topic：逻辑概念；代表一类消息
partition：分区。partition是物理上的概念，每个partition对应一个log文件。
一个topic可以分到多个partition上，每个partition是有序的队列，但不能保证topic全局有序
replica：副本。一个topic在一个partition有一个leader replica和多个follower replica

二、工作流

三、文件存储

log文件已1G为临界点，超过1G就会创建新文件
一个segement包含一个log文件、一个index文件；文件结尾是文件中第一条消息的offset-1
根据offset (1560140921)定位数据：

定位到00000000001560140916.log、00000000001560140916.index文件
1560140921 - 1560140916 + 1 = 5
根据上一步的5找到index文件中序号为5对应的地址456
根据456找到log文件中对应的消息

参考：
https://blog.csdn.net/godlovedaniel/article/details/120113667
https://blog.csdn.net/cao1315020626/article/details/112590786

zookeeper安装

testted123456 — Sun, 11 Sep 2022 14:40:45 +0000

一、安装

# tar -zxvf zookeeper-3.*.*.tar.gz
# cd zookeeper-3.*.*
# cd conf
# cp zoo_sample.cfg zoo.cfg

二、修改配置: zoo.cfg

tickTime=2000
initLimit=10
syncLimit=5
# 数据保存地址
dataDir=/Users/ted/software/apache-zookeeper-3.7.1-bin/data
# 端口
clientPort=2181

三、启动

# cd zookeeper-3.*.*
# cd bin
# 启动zookeeper
# sh zkServer.sh start
# 启动zookeeper client
# sh zkCli.sh
[zk: localhost:2181(CONNECTED) 10]ls /

kafka安装

testted123456 — Thu, 08 Sep 2022 16:40:05 +0000

一、安装

$ tar -xzvf kafka_2.13-3.2.1.tgz
$ cd kafka_2.13-3.2.1
$ cd config

二、修改配置: server.properties

broker.id=0
advertised.listeners=PLAINTEXT://127.0.0.1:9092
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
# 日志存储地址
log.dirs=/Users/ted/software/kafka_2.13-3.2.1/kafka-logs
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
# zookeeper地址
zookeeper.connect=127.0.0.1:2181
zookeeper.connection.timeout.ms=18000
group.initial.rebalance.delay.ms=0

三、命令

# 启动
$ kafka-server-start.sh -daemon ./server.properties
# 创建topic
$ kafka-topics.sh --create --bootstrap-server localhost:9092 --topic first-topic --partitions 1 --replication-factor 1
# 查看topic list
$ kafka-topics.sh --bootstrap-server localhost:9092 --list
# 查看topic具体信息
$ kafka-topics.sh --bootstrap-server localhost:9092 --topic first-topic --describe
# 修改topic的partitions
$ kafka-topics.sh --bootstrap-server localhost:9092 --alter --topic first-topic --partitions 2
# 删除topic
$ kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic first-topic
# produce 
$ kafka-console-producer.sh --topic first-topic --broker-list localhost:9092
# consume
$ kafka-console-consumer.sh --topic first-topic --bootstrap-server localhost:9092
$ kafka-console-consumer.sh --topic first-topic --bootstrap-server localhost:9092 --from-beginning

Redis-穿透、击穿、雪崩

testted123456 — Tue, 06 Sep 2022 15:27:58 +0000

一、穿透

查询的key不在redis中，请求就会打到数据库。低频穿透不要紧，要防止高频穿透。
解决方案一：短暂缓存空对象

只能保证db和redis弱一致性
如果缓存大量空对象，会占用大量内存；同时redis有LRU/LFU内存淘汰策略，会将有价值的数据淘汰

解决方案二：Bloom Filter

bloom filter认为这条数据存在，不一定存在于redis中；但bloom filter认为这条数据不存在于redis中，则一定不存在于redis中

二、穿透

“穿透”是“击穿”的特殊表现形式，热点key被击穿；比如微博的热点事件导致微博瘫痪
解决方案一：热点key不过期

可能导致db和redis不一致

解决方案二：分布式锁

热点key在redis查不到，只允许一个request打到db

三、雪崩

“雪崩”是“穿透”的特殊表现形式，多个热点key失效
原因：

过期时间比较一致，某个时间同时失效，可以将失效时间设为随机数
redis挂了，可以使用集群

解决方案一：数据预热，缓存时间随机

项目启动时将db的数据同步到redis，并设置随机值为过期时间

解决方案二：redis集群

redis-持久化

testted123456 — Sun, 04 Sep 2022 08:19:41 +0000

一、RDB快照持久化

在指定时间间隔将内存数据写入磁盘，默认持久化方式
触发方式

1. 执行save和bgsave命令
2. 配置文件设置save <seconds> <changes>规则，自动间隔性执行bgsave命令
3. 主从复制时，从库全量复制同步主库数据，主库会执行bgsave
4. 执行flushall命令清空服务器数据
5. 执行shutdown命令关闭Redis时，会执行save命令

save命令
save会阻塞redis进程，再快照创建完之前不能出来其他请求
bgsave命令

bgsave不会阻塞redis进程，会fork出一个进程把全量数据写入临时rdb文件，再替换正式rdb文件
配置文件自动触发bgsave

# 900秒内有1次key改变则触发
save 900 1
# 300秒内有10次key改变则触发
save 300 10
# 60秒内有10000次key改变则触发
save 60 10000

优点：

RDB快照是一个压缩过的非常紧凑的文件，保存着某个时间点的数据集，适合做数据的备份，灾难恢复
可以最大化Redis的性能，在保存RDB文件，服务器进程只需fork一个子进程来完成RDB文件的创建，父进程不需要做IO操作
与AOF相比，恢复大数据集的时候会更快

缺点：

RDB的数据安全性是不如AOF的，保存整个数据集的过程是比繁重的，根据配置可能要几分钟才快照一次，如果服务器宕机，那么就可能丢失几分钟的数据
Redis数据集较大时，fork的子进程要完成快照会比较耗CPU、耗时

二、AOF持久化

# appendonly参数开启AOF持久化
appendonly no

# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./

# 同步策略(always/everysec/no)
appendfsync everysec

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof出错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

# 同时开启rdb、aof
aof-use-rdb-preamble yes

append命令

开启aof，每个执行一个命令，都会把该命令以协议格式先追加到aof_buf缓存区的末尾，而不是直接写入文件，避免每次有命令都直接写入硬盘，减少硬盘IO次数
aof_buf写入aof策略：

appendfsync always：
将aof_buf缓冲区的所有内容写入并同步到AOF文件，每个写命令同步写入磁盘

appendfsync everysec：
将aof_buf缓存区的内容写入AOF文件，每秒同步一次，该操作由一个线程专门负责

appendfsync no：
将aof_buf缓存区的内容写入AOF文件，什么时候同步由操作系统来决定

rewrite命令

随着时间推移，aof文件会越来越大，rewrite就是为了缩小aof文件的大小
rewrite不是读取aof文件，而是读redis生成新的aof文件替换老的aof文件
redis-7会把数据保存到aof目录下的rdb中，同时清空aof文件
命令触发

# fork出一个进程来执行，服务器继续执行命令，且最加到aof_buf、
# aof_rewrite_buf
127.0.0.1:6379> bgrewriteaof

自动触发配置文件：

# 当AOF文件的体积大于64MB，且AOF文件的体积比上一次重写后的体积大了一倍（100%）时，会执行`bgrewriteaof`命令
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

优点：

数据更完整，安全性更高，秒级数据丢失（取决fsync策略，如果是everysec，最多丢失1秒的数据）
AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协议的格式保存的，内容是可读的，适合误删紧急恢复

缺点：

对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也会比较慢
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。不过在一般情况下，每秒 fsync 的性能依然非常高

redis-数据类型

testted123456 — Sat, 03 Sep 2022 16:58:43 +0000

string

redis 127.0.0.1:6379> SET key1 value1
redis 127.0.0.1:6379> GET key1
value1
redis 127.0.0.1:6379> DEL key1
# 设置key1过期时间（秒），可重复设置
redis 127.0.0.1:6379> expire key1 10
# 查询key1过期时间
redis 127.0.0.1:6379> ttl key1

hash

redis 127.0.0.1:6379> HMSET hash1 field1 'v1' field2 'v2'
redis 127.0.0.1:6379> HGET hash1 field1
v1
redis 127.0.0.1:6379> HDEL hash1 field1
redis 127.0.0.1:6379> HEXISTS hash1 field1

list

redis 127.0.0.1:6379> lpush list1 value1 value2
redis 127.0.0.1:6379> lrange list1 0 1

set

set是string的无序集合

redis 127.0.0.1:6379> sadd set1 a
redis 127.0.0.1:6379> sadd set1 b
redis 127.0.0.1:6379> smembers set1
a
b
redis 127.0.0.1:6379> sdiff set1 set2 set3 *返回set的差集*
redis 127.0.0.1:6379>  sinter set1 set2 *返回set的交集*
redis 127.0.0.1:6379>

sorted set

stirng有序集合

redis 127.0.0.1:6379> zadd zset1 1 value1 
redis 127.0.0.1:6379> zadd zset1 2 value2
redis 127.0.0.1:6379> zadd zset1 3 value3
redis 127.0.0.1:6379> zrange zset1 1 3 withscores
1) "value1"
2) "value2"
3) "value3"

redis-高可用

testted123456 — Wed, 31 Aug 2022 17:45:37 +0000

一、主从

1. salve连接master，发送SYNC命令
2. master接收到SYNC命令后，可以执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令
3. master执行BGSAVE后，向所有salve发送快照文件，并在发送期间继续记录被执行的写命令
4. salve收到快照文件后丢弃所有旧数据，载入收到的快照
5. master快照发送完毕后开始向salve发送缓冲区中的写命令
6. salve完成对快照的载入，开始接受命令请求，并执行来自master缓冲区的写命令，salve初始化完成
7. master每执行一个写命令就会向salve发送相同的写命令，salve接收并执行收到的写命令(salve初始化完成后的操作)
8. 出现断开重连后，2.8之后的版本会将断线期间的命令传给从数据库，增量复制。
9. 主从刚刚连接的时候，进行全量同步;
10. 全同步结束后，进行增量同步。
11. slave在任何时候都可以发起全量同步。Redis 的策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

slave配置：

slaveof 127.0.0.1 6379
#slave只读
slave-read-only yes slave只读

命令：

#查看主从信息
redis 127.0.0.1:6379>info replication
#关闭master
redis 127.0.0.1:6379>shutdown
#把slave1变成master
redis 127.0.0.1:16379>slaveof no one
#把slave2变成变成slave1的slave
redis 127.0.0.1:26379>slaveof 127.0.0.1 16379

二、哨兵

sentinel配置

# 禁止保护模式
protected-mode no
# 配置监听的主服务器，这里sentinel monitor代表监控，mymaster代表服务器的名称，可以自定义，
# 监控127.0.0.1:6379，2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor mymaster 127.0.0.1 6379 2
# sentinel author-pass定义服务的密码，mymaster是服务名称，123456是# # redis服务器密码
# sentinel auth-pass mymaster 123456

sentinel每秒ping集群中的master/salve/other sentinel
response时间大于down-after-milliseconds，sentinel则认为对方主观下线（SDOWN）
master被标记为主观下线（SDOWN），则所有sentinel每1秒确认master状态
足够数量sentinel认定master下线，则master被标记为客观下线（ODOWN）
sentinel每10秒向集群中master/salve发送info命令
当master客观下线（ODOWN），sentinel则每1秒向集群中salve发送info命令
若没有足够数量的sentinel同意master主观下线，就不会变成客观下线。若 master重新向sentinel发送ping返回有效回复，master主观下线状态就会被移除。
优点

主从自动切换

缺点

内存使用率低
难以扩容

三、集群

cluster配置

# 开启redis的集群模式
cluster-enabled yes
# 配置集群模式下的配置文件名称和位置,redis-cluster.conf这个文件是集群启# 动后自动生成的，不需要手动配置。
# cluster-config-file redis-cluster.conf

每个节点都会通过集群总线(cluster bus)，与其他的节点进行通信。通讯时使用特殊的端口号，即对外服务端口号加 10000。例如如果某个 node 的端口号是 6379，那么它与其它 nodes 通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。
机器规划

127.0.0.1 2637(master)
127.0.0.1 2638(salve)
127.0.0.1 3637(master)
127.0.0.1 3638(salve)
127.0.0.1 4637(master)
127.0.0.1 4638(salve)
扩容：
127.0.0.1 5637(master)
127.0.0.1 5638(salve)

命令

启动cluster

redis-cli --cluster create 127.0.0.1:2379 127.0.0.1:2378 127.0.0.1:3379 127.0.0.1:3378 127.0.0.1:4379 127.0.0.1:4378 --cluster-replicas 1

登录cluster

redis-cli -c -h 127.0.0.1 -p 2379

查看cluster信息

127.0.0.1:2378>cluster info
127.0.0.1:2378>cluster nodes

扩容，作为master加入cluster，但不检测是否已有数据，且没有分配slot

127.0.0.1:2378>cluster meet 127.0.0.1 5379

扩容，把new加入到cluster，old是已存在cluster中的，但没分配slot

redis-cli --cluster add-node <new_ip>:<new_port> <old_ip>:<old_port>

分配slot，随便cluster中的一个node

redis-cli --cluster reshard 127.0.0.1:2379
#根据提示指定要被分配的node
#根据提示知道要分配的slot数

master分配了slot，添加salve

1. 通过slave登录cluster
2. 通过master node id复制数据
#redis-cli -c -h 127.0.0.1 -p 5378
127.0.0.1:5378>cluster replicate <master_node_id>

下线

redis-cli --cluster reshard 127.0.0.1:2379
# 指定要重新分配的slot数量
# 指定接受slot的node id
# 指定source node id
# 输入done

删除node

127.0.0.1:2378>cluster forget <node_id>

插槽（slot）

1. 插槽范围0～16383，会平均分配在master上
2. redis把key通过crc16算法计算出结果，然后和16384求余，找到对应的节点
如果超过1/2的master认为一个master宕机，此master就被下线
3. 如果master和对应salve都宕机，整个集群就挂掉

优点：

可扩展：可扩展到1000多个节点
高可用：
master挂了，可以自动failover，用投票完成salve到master提升；
节点之间通过gossip协议完成交换信息

缺点：

gossip有消息的延迟和冗余，浪费一定到带宽