对照视频敲呗

改一下压测数据试试呢，比如改成一共一百万个请求，可同时并发执行50万个请求

IO多路复用是正确的。

这里的阻塞是指一个命令的执行会阻塞其它命令，因为redis只有一个线程用于执行命令。

nice

A  执行了 incrby后 等于  100   A就中奖    一旦 incrby > 100   就是未中奖

这个例子的重点不是是否中奖，中奖概率是100%，意思就是在数量达到限制之前进入的全部中奖，所以就不必考虑未中奖的情况。这个例子目的是演示计算器控制的并发问题

你打错了吧v1if判断那个

是没有设置好日志输出的文件

可不可以这样理解，判断操作和set操作为2个操作，A先进行了判断操作，在进行set操作之前，B进行了判断操作，如此才导致A和B都判断为空，进行set

假如B在判断为空操作后，网络延迟了，直到A进行了incrby操作后，才进行set，这样就会出现问题了

你用什么工具做的测试？

我的一个github项目供你参考  https://github.com/limen/fastrq-php

很严谨

第一个问题，不能确定成功的请求就先写入日志文件，因为并发场景下多个请求之间是互相独立的。

第二个问题，确实是这样，生产环境key的命名需要有一个统一的规范。

-2是已过期

看错了，第一次敲漏了，后来老师补上了

准确地讲redis server有一个进程，包含了多个线程，其中只有一个线程用于处理客户端请求。

redis本身没有并发问题，如你所说。这里讲的是一个限量抽奖的程序，用redis做并发控制，防止抽奖过量。

有一些包装好的终端工具，如zsh，可以联想、自动补全。Redis命令行是否有提示和版本有关。

increase的缩写，对一个key的值加1