#redis也可以实现队列，为什么还要用rabitmq或者kafka?
这篇文章算是我最近对工作中队列的思考。
在工作中，用到的队列都是redis来实现，那为什么还要其它的消息队列呢？
在网上搜了一圈，发现了这篇文章redis也可以实现队列，为什么还要用rabitmq或者kafka?，现在只是把它摘录过来，防止后续链接失效。
直接写文件也能实现key-value啊，为什么还要redis？
抛开业务场景谈这些组件的选择就是耍流氓。 负载不大，可靠性要求不高，没有扩容需求的情况下自然都一样，甚至就像之前说的，不用redis，就写文件都行，往某个文件夹里写个文件=>入队，拿出来删掉=>出队
至于ack啊，分布式啊，抗压啊等等各种问题，redis基本没有现成解决方案，有的可以自己变通解决，有的就是解决不了，所以才会有各种各样的专业队列组件，有的注重速度，有的注重分布式，有的注重可靠性，他们都会试图解决redis解决不了的一些问题。就好像你磁盘写文件当key-value用，IO的速度自然成为瓶颈，负载能力上不去，所以才会有专业的redis来做内存的kv
还有一篇文章说在使用redis入队时，数据较小，redis性能很高，如果数据大小超过10K时，则redis出奇地慢，这个我没有测试，先姑妄听之，在编程中注意一下放入redis的队列的数据大小就可以了。
最后一点，系统中用户登录后生成的token是通过UUID生成唯一性标志后缓存入redis，并设置超时时长，并没有将token信息存入数据库。如果redis服务器挂了，那所有用户的登录信息都将会丢失，导致所有登录的用户又要重新登录。虽然redis服务器挂了的可能性不大，但如果真有这么一天，那用户体验还是很差的。还是redis和数据库结合来做登录超时比较可靠。