验证码使用redis队列预生成的可行性论证

最近景区业务量增大，OTA平台的请求增加，造成了服务器明显的出现访问数据延长。查看了下问题，发现是在生成验证码阶段出现了问题。所以急需进行优化：

先列出下问题：

因为开发之初为了考虑验证码的安全性。而且参考了其他的平台可以直接用验证码取票，这个用户体验挺好的。所以开始是计划直接用验证码取票的。但是在使用后发现，直接验证码取票的话验证码的位数需要保持在10位左右的长度。之前在买电影票取票的时候我就特别头疼这么长的验证码。特别是朋友代买我是用手机短信看验证码的时候，有时候眼花输错一位后面十几个人排队，这个就有点尴尬了。所以计划是尽量控制在6位以内，最好是一口气能读出来。手机号是自己的的话，可以保证验证码是11位+的安全位数。

但是设计之初会出现验证已经在使用未核销的验证码的存量。这个业务量上来之后是个耗时操作。系统随机验证码官方说的是其实是伪随机。所以，我想出一个方案是，在非忙时，或者使用副库用go或者直接是php生成可用验证码，到队列。然后在需要验证码的时候直接从队列中拉取，如果在不需要考虑是否安全的情况下。有一下多个优点：

1. 不需要再考虑锁和事务的问题了。之前在生产验证码的时候需要添加锁和事务防止在小概率情况下生成相同的验证码给相同的手机号。使用redis队列后，因为是队列操作，所以这问题就不需要考虑太多了。
2. 性能问题，之前在使用.NET生成验证码的时候。压测发现在小核心数设备上压力过大的时候验证码会出现重叠的情况。现在直接添加队列，数据可控，延用了redis高性能特性。
3. 错峰消耗服务器资源，在闲时生成验证码，消耗服务器多余的资源，在忙时节约服务器多余资源的开销
4. 等等等等

这个方案还在论证，看到的朋友如果有什么性能安全上的 建议可以告诉我，邮箱在页脚。