异步消息队列

Redis的list数据结构常用来作为异步消息队列使用，使用rpush/lpush操作入队，使用lpop/rpop来操作出队

方案

setnx + del

1
2
3
4
5

> setnx lock:user true
OK
# 执行业务逻辑
> del lock:user
(integer) 1

存在的问题：如果逻辑执行过程中出现异常，可能会导致del指令没有被调用，陷入死锁，锁永远不会被释放

数据结构

Redis所有的数据结构都是以唯一的key字符串作为名称，然后通过该唯一key值来获取相应的value值

string

1. Redis的字符串是动态字符串，是可以修改的字符串，内部结构实现上类似与Java的ArrayList
   • 采用预分配冗余空间的方式来减少内存的频繁分配
2. 当字符串长度小于1M时，扩容都是加倍现有的空间，如果超过1M，扩容时一次只会多扩1M的空间
   • 字符串最大长度为512M

调优目标

1. 主要目标：高吞吐量、低延时
2. 吞吐量
   • 即TPS，指的是Broker端进程或Client端应用程序每秒能处理的字节数或消息数
3. 延时，可以有两种理解
   • 从Producer发送消息到Broker持久化完成之间的时间间隔
   • 端到端的延时，即从Producer发送消息到Consumer成功消费该消息的总时长

主机监控

1. 主机监控：监控Kafka集群Broker所在的节点机器的性能
2. 常见的主机监控指标
   • 机器负载
   • CPU使用率
   • 内存使用率，包括空闲内存和已使用内存
   • 磁盘IO使用率，包括读使用率和写使用率
   • 网络IO使用率
   • TCP连接数
   • 打开文件数
   • inode使用情况

背景

1. 命令行脚本只能运行在控制台上，在应用程序、运维框架或者监控平台中集成它们，会非常困难
2. 很多命令行脚本都是通过连接ZK来提供服务的，这会存在潜在的问题，即绕过Kafka的安全设置
3. 运行这些命令行脚本需要使用Kafka内部的类实现，也就是Kafka服务端的代码
   • 社区是希望用户使用Kafka客户端代码，通过现有的请求机制来运维管理集群
4. 基于上述原因，社区于0.11版本正式推出Java客户端版的KafkaAdminClient

脚本列表

1
2
3
4
5
6
7
8

connect-distributed              kafka-consumer-perf-test         kafka-reassign-partitions        kafka-verifiable-producer
connect-standalone               kafka-delegation-tokens          kafka-replica-verification       trogdor
kafka-acls                       kafka-delete-records             kafka-run-class                  zookeeper-security-migration
kafka-broker-api-versions        kafka-dump-log                   kafka-server-start               zookeeper-server-start
kafka-configs                    kafka-log-dirs                   kafka-server-stop                zookeeper-server-stop
kafka-console-consumer           kafka-mirror-maker               kafka-streams-application-reset  zookeeper-shell
kafka-console-producer           kafka-preferred-replica-election kafka-topics
kafka-consumer-groups            kafka-producer-perf-test         kafka-verifiable-consumer

背景

1. Kafka和传统的消息引擎在设计上有很大的区别，Kafka消费者读取消息是可以重演的
2. 像RabbitMQ和ActiveMQ等传统消息中间件，处理和响应消息的方式是破坏性
   • 一旦消息被成功处理，就会从Broker上被删除
3. Kafka是基于日志结构（Log-based）的消息引擎
   • 消费者在消费消息时，仅仅是从磁盘文件中读取数据而已，是只读操作，因为消费者不会删除消息数据
   • 同时，由于位移数据是由消费者控制的，因此能够很容易地修改位移值，实现重复消费历史数据的功能
4. Kafka Or 传统消息中间件
   • 传统消息中间件：消息处理逻辑非常复杂，处理代价高、又不关心消息之间的顺序
   • Kafka：需要较高的吞吐量、但每条消息的处理时间很短，又关心消息的顺序

背景

1. Kafka安装目录的config路径下，有server.properties文件
   • 通常情况下，会指定server.properties来启动Broker
   • 如果要设置Broker端的任何参数，必须要显式修改server.properties，然后重启Broker，让参数生效
   • 但在生产环境，不能随意重启Broker，因此需要能够动态修改Broker端参数
2. 社区于1.1.0正式引入了动态Broker参数
   • 动态指的是修改参数后，无需重启Broker就能立即生效，而之前server.properties中配置的参数称为静态参数
3. 并非所有Broker端参数都可以动态调整的，官方文档中有Dynamic Update Mode一列
   • read-only
     • 与原来的参数行为一样，只有重启Broker，才能令修改生效
   • per-broker
     • 动态参数，修改之后，只会在对应的Broker上生效
   • cluster-wide
     • 动态参数，修改之后，会在整个集群范围内生效

慢SQL诱因

1. 无索引、索引失效
2. 锁等待
   • InnoDB支持行锁，MyISAM支持表锁
   • InnoDB支持行锁更适合高并发场景，但行锁有可能会升级为表锁
     • 一种情况是在批量更新时
     • 行锁是基于索引加的锁，如果在更新操作时，条件索引失效，那么行锁会升级为表锁
   • 基于表锁的数据库操作，会导致SQL阻塞等待，影响执行速度
     • 在写大于读的情况下，不建议使用MyISAM
   • 行锁相对于表锁，虽然粒度更细，并发能力提升，但也带来了新的问题，那就是死锁
3. 不恰当的SQL
   • SELECT *
   • SELECT COUNT(*)
   • 大表中使用LIMIT M,N
   • 对非索引字段进行排序