1. 慢日志设置1234# 当命令耗时超过5毫秒时，记录慢日志CONFIG SET slowlog-log-slower-than 5000# 只保留最近500条慢日志CONFIG SET slowlog-max-len 500 2. 查看慢日志123456789101112131415127.0.0.1:6379> SLOWLOG get 51) 1) (integer) 32693 # 慢日志ID 2) (integer) 1593763337 # 执行时间戳 3) (integer) 5299 # 执行耗时(微秒) 4) 1) "LRANGE" # 具体执行的命令和参数 2) "user_list:2000" 3) "0" 4) "-1"2) 1) (integer) 32692 2) (integer) 1593763337 3) (integer) 5044 4) 1) "GET" 2) "user_info:1000"...
Watchtower 官网: https://github.com/containrrr/watchtower Watchtower 可以用于自动更新 Docker 镜像与容器。Watchtower 会监视正在运行的容器以及相关的镜像，当检测到 Registry 中的镜像与本地的镜像有差异时，会拉取最新镜像并使用最初部署时相同的参数重新启动相应的容器。
1. 缓存雪崩在短时间内本应交由 Redis 处理的大量请求，都发送到了数据库进行处理，从而导致对数据库的压力迅速增大，严重时数据库可能崩溃，从而导致整个系统崩溃，就像雪崩一样，引发连锁效应，所以叫缓存雪崩。 出现上述情况的常见原因主要有以下两点： 大量缓存数据同时过期，导致本应请求到缓存的需重新从数据库中获取数据。 redis 本身出现故障，无法处理请求，那自然会再请求到数据库那里。 针对大量缓存数据同时过期的情况： 实际设置过期时间时，应当尽量避免大量 key 同时过期的场景，如果真的有，那就通过随机、微调、均匀设置等方式设置过期时间，从而避免同一时间过期。 添加互斥锁，使得构建缓存的操作不会在同一时间进行。 双 key 策略，主 key 是原始缓存，备 key 为拷贝缓存，主 key 失效时，可以访问备 key，主 key 缓存失效时间设置为短期，备 key 设置为长期。 后台更新缓存策略，采用定时任务或者消息队列的方式进行 redis 缓存更新或移除等。 针对 Redis 本身出现故障的情况： 在预防层面，可以通过主从节点的方式构建高可用的集群，也就是实现主 Redis 实例挂掉后，能有其他从库快速切换为主库，继续提供服务。 如果事情已经发生了，那就要为了防止数据库被大量的请求搞崩溃，可以采用服务熔断或者请求限流的方法。当然服务熔断相对粗暴一些，停止服务直到 redis 服务恢复，请求限流相对温和一些，保证一些请求可以处理，不是一刀切，不过还是看具体业务情况选择合适的处理方案。
本文使用的工具都是 Windows SDK 自带的，可以采用单独安装 Windows SDK的方式，也可以通过安装 Visual Studio 来附带安装 Windows SDK。 123456# 在弹出界面设置密码123456makecert.ex...
所谓音频环回录制就是录制扬声器播放的声音。播放到扬声器的声音已经过混合，Windows 提供了 WASAPI 来获取这种混合的音频信号。 本文将录制到原始音频样本数据写入到文件，可以使用Audacity导入原始数据试听。
选择一项事业（或者找一条能够载渡精神的船）的时候，应该想起兵书上的一句话：知己知彼，百战不殆。没有谁是为了失败而工作的，因为注定的失败不能引导出一个如醉如痴的过程。 所谓知己，就是要知道自己的兴趣何在？自己的禀赋何在？如果你喜欢文学，可你偏偏不肯舍弃一个学化学的机会，且不说没有兴趣你的化学很难学好，即便你小有成就那也是你的悲剧。如果你是一个数学天才，比如说是一个潜在的陈景润，可你对此昏然不知偏要去当一个写小说的，结果多半不妙。 所谓知彼，就是得知道客观条件允许你干什么。如果你热爱起足球的时候已经 40 多岁，你最好安心作一个球迷，千万别学马拉多纳了。如果你羡慕三毛，你也有文学才能，但是你的双腿一动都不能动，你就不要向往撒哈拉，你不如写一写自己心中的沙漠。 我一贯相信，每个人都有自己的所长，倘能扬长避短谁都能有所作为；相反如果弃长取短，天才也能成为蠢才，不信让陈景润与托尔斯泰调换一下工作试试看。对事业的选择，要根据“知己知彼”的原则，可别为“热门”或时髦所左右。
本文介绍如何根据进程 ID 获取进程命令行参数，使用 Windows NTDLL 提供的未公开 API 实现。 由于需要使用到Windows应用层未公开的 API，而且这些 API 在 Windows 头文件中未提供函数定义，因此我们需要使用GetProcessAddress动态地从 ntdll.dll 中获取函数地址。 动态获取函数地址本不是一件困难的事情，但是当涉及调用函数比较多时，这个操作就显得比较繁琐了，我们可以直接使用下面的库来简化上述操作。https://github.com/winsoft666/ndk
rpclib是一个 C++的 RPC 库，基于 MessagePack 进行二进制序列化和反序列化，底层使用 TCP 进行进程间通信。其功能与 Facebook 的 Thrift、Google 的 Protocol Buffers 相似，但 rpclib 更加轻量级，不需要依赖 Boost，而且不用声明接口描述文件。
