大家好，如果您还对海量数据下如何正确访问Redis服务才不会挂掉不太了解，没有关系，今天就由本站为大家分享海量数据下如何正确访问Redis服务才不会挂掉的知识，包括redis不建议分库的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！

本文目录

1. 现在决定报班学习了，在纠结java还是web有好的建议吗
2. 海量数据下如何正确访问Redis服务才不会挂掉
3. web端常用架构

现在决定报班学习了，在纠结java还是web有好的建议吗

你好，我觉得选JAVA会好一点，为什么真么说，主要原因有以下几点：

第一，JAVA是一个系统的语言，自诞生依赖一直非常的流行，JAVA的应用面非常的广泛，无论是桌面系统还是web系统都需要JAVA来处理。

第二，目前很多互联网行业都是JAVA语言为基础，虽然web现在越来越广泛，但是JAVA的面还是比web要广，况且web目前来看虽然也很热门，但是毕竟很多东西还是需要依赖服务端的东西。

第三，就实际来看，JAVA的发展也要比web好一些，毕竟像大数据等技术都是基于JAVA需要开发的，而且在项目组中一般也是JAVA开发人员作为主导。

第四，从两者的语言特性来看，JAVA的底层实质更加丰富，而web相对来说比较单一，更多的是框架的不断演变，封装，这无疑也增加了学习成本。

海量数据下如何正确访问Redis服务才不会挂掉

要保证Redis不会挂掉，也就是提高Redis的高可用性，可以从这么几个方面考虑。

集群式部署方式

Redis单副本：也就是只部署一台Redis，不需要节点之间的数据同步，架构简单，部署方便；但是单台机器毕竟是有风险的，按照题目中【海量数据】的场景，是不能达到高可用要求的。

Redis主从：主从实例可以部署在不同的物理服务器上，充分利用多台服务器的资源，在主库发生故障的时候，可以进行主备切换，从而保证系统的稳定运行，甚至可以做到读写分离，主库专门用作写操作，一台或多台备库进行读操作；但是当主库发生故障的时候（如果没有HA方案的话），是需要手动进行主备切换的。

RedisSentinel：部署架构分为两部分【Sentinel集群】和【数据集群】；Sentinel集群是由多个Sentinel节点组成的分布式集群，通常是2N+1台服务器，可以实现故障发现和转移、客户端通知等功能；数据集群用于存储数据；它能够解决主从模式下的自动切换问题，并且数据集群是可以横向扩展的；当然这个架构实现和部署起来，也更为复杂一些；并且这个架构不能做到读写分离。

RedisCluster：Redis3.0集群，是分布式集群解决方案之一，物理架构中配置2N个节点（主从一一对应），主节点提供读写操作，从节点作为备份；数据分布保存在多个节点上，是一种无中心的架构，如果有部分节点发生故障，能够实现故障自动转移和切换，用投票机制完成备库升级为主库（下文的Redis分片章节，还会介绍到RedisCluster）。

Redis分片

Redis在3.0之前只支持单实例，在此之前，在数据量比较大的情况，通常有几种方案可以做到把数据分片保存到多台服务器上。

客户端分片：分片逻辑被放到了客户端上，由客户端根据路由规则，把数据保存不同的Redis实例中，读取的时候也是根据规则，去对应的实例上读取数据；但是当Redis实例数量发生变化的时候（增加实例或减少实例），需要手动地调整分片的规则程序；并且这种部署方式，也增加了运维的成本。

Redis代理组件：在这种架构中，客户端不再直接访问Redis实例，而是访问代理组件，由它管理路由的规则；客户端不需要关心有几个Redis实例，数据被路由到哪个实例上；但是由于在客户端和Redis之间增加了一层代理，多多少少也会产生一些性能上的损耗。

RedisCluster：上文中提到的Redis3.0集群，这里对数据的存储和路由方式，再介绍几句：Redis把所有的Key分成了16384个slot，每个Redis实例负责其中一部分slot；每个Redis都知道每个slot在哪个节点上存储（实例节点定期做数据交换）；当客户端访问到一个Redis实例的时候，如果数据不在这个实例上，那么会通过重定向命令引导客户端访问数据所在的实例。

热点数据挑战单节点的极限

虽然我们已经把数据分散保存到多台Redis实例上了，但是如果有一个热点数据被频繁访问，超过了单实例的服务器极限，那么该如何解决呢？通常的手段就是做读写分离，部署多台只读节点，对外提供服务。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

web端常用架构

一、单DB架构

??单DB架构一般就是nginx直接upstream请求到后端Tomcat，扩容时基本是增加新的Tomcat实例，然后通过Nginx负载均衡upstream过去，此时数据库还不是瓶颈，但是当访问量达到一定级别后数据库的压力就上来了，单个数据库可能扛不住，可以通过分表分库或者读写分离加缓存来解决。

二、DB+Cache/数据库读写分离架构

??此时通过使用数据库读写分离或者Redis这种缓存来支撑更大的访问量，但是使用缓存会存在与数据库数据不一致的问题，或者Redis不能直接命中数据库导致数据库压力过大，可以考虑使用Redis的主从或者用一致性哈希算法做分片的Redis集群。使用缓存这种架构，要求应用对数据一致性的要求不是很高。

三、OpenResty+LocalRedis+Mysql集群架构

??OpenResty首先通过Lua读取本机Redis缓存，如果命不中，则回源到后端Tomcat集群，后端Tomcat集群再读取Mysql数据库，Redis都是安装到和OpenResty同一台服务器上，OpenResty直接读取本机可以减少网络延时。Redis通过主从方式同步数据。

四、OpenResty+Redis集群+Mysql集群架构

??此时架构与之前架构不同的是，此时我们使用一致性哈希算法实现Redis集群，而不是读取本机Redis，保证其中一台不可用时，只有很少的数据会丢失，防止击穿到数据库。Redis集群分片可以使用Twemproxy如果Tomcat实例很多的话，就要考虑Redis和Mysql链接数问题，因为大部分Redis/Mysql客户端都是通过连接池实现，此时链接数会成为瓶颈，一般方法是通过中间件来减少链接数。

??此时的问题就是Twemproxy实例众多，应用维护、配置困难，需要在这之上做负债均衡，比如，通过LVS/HaProxy实现VIP(虚拟Ip)，可以做到切换对应用透明，故障自动转移。还可以通过实现内网DNS来做其负载均衡。

好了，关于海量数据下如何正确访问Redis服务才不会挂掉和redis不建议分库的问题到这里结束啦，希望可以解决您的问题哈！