StackExchange.Redis 系列 6:Events 说明

  • 本系列博文是“伪”官方文档翻译,并非完全将官方文档进行翻译,而是我在查阅、测试原始文档并转换为自己东西后进行的“准”翻译。
  • 原始文档见此:https://stackexchange.github.io/StackExchange.Redis/
  • 本系列本博文基于 redis 5.0.6,系列中部分博文跟官方文档有出入,有不同见解 / 说明不当的地方,还请大家不吝拍砖。

ConnectionMultiplexer 对外提供了多个事件以便让你可以捕获内部执行情况,你可以通过这些事件按需记录日志。

事件

  • ConfigurationChanged:当 ConnectionMultiplexer 中的连接发生改变的时候该事件会被触发。
  • ConfigurationChangedBroadcast:当通过 pub/sub 接收到重新配置的消息时,该事件会被触发。通常情况下,引发该事件的是调用 IServer.MakeMaster 去改变一个节点的副本配置(该节点可以将此类请求广播到所有客户端。)
  • ConnectionFailed:任何原因导致物理连接失败的时候会触发该事件。在下次连接被重新成功建立前,该事件只会触发一次。
  • ConnectionRestored:在上一次连接失败后,连接重新被建立(恢复)的时候,会触发该事件。
  • ErrorMessage:当 Redis 服务端用错误信息响应客户端请求的时候,该事件会被触发。另外,触发该事件后,常规的异常/错误依然会返回/告知到调用方。
  • HashSlotMoved:使用“redis 集群”的时候,当 hash-slot 在节点间发生迁移的时候,该事件就会别触发。注意,请求会自动重新路由,一般用户不需要做什么特殊操作。
  • InternalError:当 StackExchange.Redis 库内部发生错误的时候会触发该事件,一般在 DEBUG 的时候可以使用该事件。

请注意,StackExchange.Redis中的 pub/sub 实现与事件类似,Subscribe / SubscribeAsync 方法接受一个 Action<RedisChannel,RedisValue> 回调,该回调在收到消息时会被触发。

StackExchange.Redis 系列 5:事务

  • 本系列博文是“伪”官方文档翻译,并非完全将官方文档进行翻译,而是我在查阅、测试原始文档并转换为自己东西后进行的“准”翻译。
  • 原始文档见此:https://stackexchange.github.io/StackExchange.Redis/
  • 本系列本博文基于 redis 5.0.6,系列中部分博文跟官方文档有出入,有不同见解 / 说明不当的地方,还请大家不吝拍砖。

Redis 中的事务说明

  • Redis 中的事务跟我们常说的数据库事务不同:
    • 数据库事务必须保证全部成功,否则就回滚。
    • 而 Redis 中的事务更偏向于“一组打包的批量执行脚本”,其中任何一条命令的执行失败,不会导致已经执行的命令回滚,也不会中断后续的命令执行。
  • 在使用数据库事务的时候,你可以在事务中使用条件判断。但在 Redis 事务中,你无法使用条件判断。(条件见下方说明)

如何使用事务?

  • 在 Redis 原生命令中使用 MULTI 来开启事务,EXEC 来执行事务(或者 DISCARD 来取消事务)
  • 一旦使用 MULTI,在 MULTI 之后的命令不会立即执行,它们会排队,直到接收到 EXEC命令。如果接收到的时 DISCARD 命令,则所有已传输的命令会全部抛弃。
    • 因为 Redis 命令会排队执行,所以无法在 Redis 中使用条件判断。

StackExchange.Redis 系列 4:Keys, Values and Channels 说明

  • 本系列博文是“伪”官方文档翻译,并非完全将官方文档进行翻译,而是我在查阅、测试原始文档并转换为自己东西后进行的“准”翻译。
  • 原始文档见此:https://stackexchange.github.io/StackExchange.Redis/
  • 本系列本博文基于 redis 5.0.6,系列中部分博文跟官方文档有出入,有不同见解 / 说明不当的地方,还请大家不吝拍砖。

Keys

  • 在 redis 的数据库中,key 是唯一的。
  • 在集群或者分片系统中,key定义了包含该数据的节点,因此 key 对于 routing commands而言相当重要。
  • 在 StackExchange.Redis 中,通过 RedisKey 这个类型来表示 keys。内部已经做好了 string 和 byte[] 类型之间的转换。并且允许你使用”字符串“作为键,或者”字节数组“作为键,如:

string key = ...;
db.StringIncrement(key);
//以上命令等价于
byte[] key = ...
db.StringIncrement(key);
  • StackExchange.Redis 提供了获取 key 的操作,且相当便利,如下:

StackExchange.Redis 系列 3:Pipelines and Multiplexers 说明

  • 本系列博文是“伪”官方文档翻译,并非完全将官方文档进行翻译,而是我在查阅、测试原始文档并转换为自己东西后进行的“准”翻译。
  • 原始文档见此:https://stackexchange.github.io/StackExchange.Redis/
  • 本系列本博文基于 redis 5.0.6,系列中部分博文跟官方文档有出入,有不同见解 / 说明不当的地方,还请大家不吝拍砖。

Pipeline

  • 在使用 Redis 的时候,大部分的耗时会集中在网络延时上,通过 Pipeline,可以把多次网络请求合并为 1 次,提高性能。

当你执行如下同步方法的时候:

string a = db.StringGet("a");
string b = db.StringGet("b");
  • 只有等你得到了 a 的值以后,获取 b 的值的请求才会发出去。

StackExchange.Redis 系列 2:配置

  • 本系列博文是“伪”官方文档翻译,并非完全将官方文档进行翻译,而是我在查阅、测试原始文档并转换为自己东西后进行的“准”翻译。
  • 原始文档见此:https://stackexchange.github.io/StackExchange.Redis/
  • 本系列本博文基于 redis 5.0.6,系列中部分博文跟官方文档有出入,有不同见解 / 说明不当的地方,还请大家不吝拍砖。

配置概述

StackExchange.Redis 提供了丰富的配置,你可以在调用 Connect / ConnectAsync 方法的时候进行设定,如下

var conn = ConnectionMultiplexer.Connect(configuration);
  • configuration 可以是一个 ConfigurationOptions “实例”或者一个 “代表配置内容的string 字符串”

StackExchange.Redis 系列 1:基础使用

  • 本系列博文是“伪”官方文档翻译,并非完全将官方文档进行翻译,而是我在查阅、测试原始文档并转换为自己东西后进行的“准”翻译。
  • 原始文档见此:https://stackexchange.github.io/StackExchange.Redis/
  • 本系列本博文基于 redis 5.0.6,系列中部分博文跟官方文档有出入,有不同见解 / 说明不当的地方,还请大家不吝拍砖。

ConnectionMultiplexer 说明

命名空间位于:StackExchange.Redis.ConnectionMultiplexer

  • ConnectionMultiplexer 是 StackExchange.Redis 的核心对象,内部继承了 IDisposable,但建议不要用 using 以便可以愉快重用,你就认为它足够安全吧。
  • 该对象线程安全,且应该被重用,搞成单例即可,不要每次操作都创建一个。

主从库示例:

ConnectionMultiplexer redis = ConnectionMultiplexer.Connect("server1:6379,server2:6379");

通过设置注册表提高 P2P/IIS 并发数

写在前面

  • 在执行性能测试(如用 JMeter 直接压接口)的时候,有的时候并发数上不去、本机大面积出现 TCP 状态为 TIME_WAIT,除了放开 TCP 端口数和调整默认 TCP 释放时间外,另外几个注册表项同样重要且需要调整。
  • 以下设置项针对的是本机和远端机。
  • 设置完成后,重启下电脑使生效。

结合“性能监视器” 排查、处理性能瓶颈导致应用吞吐率等指标上不去的问题

双11备战前夕,总绕不过性能压测环节,TPS 一直上不去 / 不达标,除了代码上的问题外,服务器环境、配置、网络、磁盘、CPU 亦是导致性能瓶颈的重要一环,本文旨在分享最近项目性能压测过程中的排查经验,文中的表单你可以作为排查手册保存,如有不对之处,还请在评论区分享、交流你的经验和观点:)

通过本文,你可以了解和掌握:

  • 了解常见的系统瓶颈的可能原因。
  • 通过性能探查器定位性能瓶颈。
  • 几点关于性能优化的策略。
  • 一份关于 windows 性能监视器的部分计数器翻译及对应的经验结论。