redis集群部署的几种方案
Redis在实际应用中，是单独部署在一个服务器中，还是和项目跑在一个服务器中，还是跑在数据库服务器？
Redis在实际应用中，是单独部署在一个服务器中，还是和项目跑在一个服务器中，还是跑在数据库服务器？
理论上是独立部署最好。但实际情况吧看公司机器资源。不从实际情况考虑的架构都是耍流氓。redis主要耗内存。但生产环境中cpu，网络，磁盘都是要考虑的问题，而且我们的资源是有限的。
可以肯定的是最好不要和数据库在同一个节点部署。数据库需要单独部署。为什么这样说呢? 一个原因是因为数据库太重要了。我们不能因为redis的问题导致数据库被牵连。另一个原因。redis作为缓存，本身就是为了减少直接连库的压力。结果部署在一个节点上。数据库实例的压力是小了。但这个节点整体访问量，IO，cpu，内存并没有减小多少。甚至是增加了。因为一次请求要吗访问数据库，要吗访问redis，但现在都在一个节点上， 所以总量并没有减小。而redis自身还会淘汰数据，这其中又是一波耗节点资源的操作。
从另一个理想的角度考虑，我希望我的数据库实例挂了，能从redis中获取数据。我的redis挂了，能从数据线中获取数据。这样尽量保证业务正常。要实现这个目标，数据库和redis必须在不同的节点上。如果在同一个节点。而这个节点挂了。我们就没有取数据的地方了。
生产环境，中间件之间可以混合部署。比如redis，mq可以在同节点混合部署。业务项目之间可以混合部署。但业务不要和中间件部署到同节点。数据库独立节点部署。
redis最好也不要和其他的耗内存大户混合部署，如elasticsearch 这种的。
如果没有中间件节点。那就选个业务访问量少的节点混合部署吧，总之不要选数据库节点。除非这个数据库节点是冷备节点
redis如果list较大，如何优化？
redis就是设计来存较大list的。不需要优化。
所以你遇到的问题是其他问题，比如io吞吐等问题。
1，如果已经存在这个大list，获取数据不要全部提取，分页取
2，不要往大list继续塞新数据，可“分片”存多list
3，作为缓存list存热数据，冷数据存db吧
一般list比较多，都是拆分redis key，分多个list存储，同时可以看下前端展示多少条，建议redis list只存储前几页数据，后面页的数据走db查询
1.可以用分片集群。让一个大list散在多个节点上。
2.看你用list存储有什么场景，可以考虑其他类型的。sortedset是一个很好用的类型
建议纬度分小点，转换成二进制存储
按一定规则进行数据分组。使用不同的key保存不同的组。如果数据量再大的话可以不同redis中保存。