监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移 *** 作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统, 你可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。
虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel , 但实际上它只是一个运行在特殊模式下的 Redis 服务器, 你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动 Redis Sentinel 。
Redis Sentinel 目前仍在开发中, 这个文档的内容可能随着 Sentinel 实现的修改而变更。
Redis Sentinel 兼容 Redis 2416 或以上版本, 推荐使用 Redis 280 或以上的版本。可能是三国杀服务器或者电脑软件出现了问题
具体原因如下:
1、三国杀官方服务器维护,游戏无法访问数据库服务器,等待官方网站通知。
2、三国杀本地客户端安装版本太旧导致数据访问错误,尝试重装游戏软件。
3、电脑软件安装盘丢失相关文件,建议重装游戏软件。
4、IE版的三国杀缓存满了,建议清空缓存后再尝试连接
通常来说,当数据多、并发量大的时候,架构中可以引入Redis,帮助提升架构的整体性能,减少Mysql(或其他数据库)的压力,但不是使用Redis,就不用MySQL。
因为Redis的性能十分优越,可以支持每秒十几万此的读/写 *** 作,并且它还支持持久化、集群部署、分布式、主从同步等,Redis在高并发的场景下数据的安全和一致性,所以它经常用于两个场景:
缓存
判断数据是否适合缓存到Redis中,可以从几个方面考虑: 会经常查询么?命中率如何?写 *** 作多么?数据大小?
我们经常采用这样的方式将数据刷到Redis中:查询的请求过来,现在Redis中查询,如果查询不到,就查询数据库拿到数据,再放到缓存中,这样第二次相同的查询请求过来,就可以直接在Redis中拿到数据;不过要注意缓存穿透的问题。
缓存的刷新会比较复杂,通常是修改完数据库之后,还需要对Redis中的数据进行 *** 作;代码很简单,但是需要保证这两步为同一事务,或最终的事务一致性。
高速读写
常见的就是计数器,比如一篇文章的阅读量,不可能每一次阅读就在数据库里面update一次。
高并发的场景很适合使用Redis,比如双11秒杀,库存一共就一千件,到了秒杀的时间,通常会在极为短暂的时间内,有数万级的请求达到服务器,如果使用数据库的话,很可能在这一瞬间造成数据库的崩溃,所以通常会使用Redis(秒杀的场景会比较复杂,Redis只是其中之一,例如如果请求超过某个数量的时候,多余的请求就会被限流)。
这种高并发的场景,是当请求达到服务器的时候,直接在Redis上读写,请求不会访问到数据库;程序会在合适的时间,比如一千件库存都被秒杀,再将数据批量写到数据库中。
所以通常来说,在必要的时候引入Redis,可以减少MySQL(或其他)数据库的压力,两者不是替代的关系 。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。
Redis和MySQL的应用场景是不同的。
通常来说,没有说用Redis就不用MySQL的这种情况。
因为Redis是一种非关系型数据库(NoSQL),而MySQL是一种关系型数据库。
和Redis同类的数据库还有MongoDB和Memchache(其实并没有持久化数据)
那关系型数据库现在常用的一般有MySQL,SQL Server,Oracle。
我们先来了解一下关系型数据库和非关系型数据库的区别吧。
1存储方式关系型数据库是表格式的,因此存储在表的行和列中。他们之间很容易关联协作存储,提取数据很方便。而Nosql数据库则与其相反,他是大块的组合在一起。通常存储在数据集中,就像文档、键值对或者图结构。
2存储结构关系型数据库对应的是结构化数据,数据表都预先定义了结构(列的定义),结构描述了数据的形式和内容。这一点对数据建模至关重要,虽然预定义结构带来了可靠性和稳定性,但是修改这些数据比较困难。而Nosql数据库基于动态结构,使用与非结构化数据。因为Nosql数据库是动态结构,可以很容易适应数据类型和结构的变化。
3存储规范关系型数据库的数据存储为了更高的规范性,把数据分割为最小的关系表以避免重复,获得精简的空间利用。虽然管理起来很清晰,但是单个 *** 作设计到多张表的时候,数据管理就显得有点麻烦。而Nosql数据存储在平面数据集中,数据经常可能会重复。单个数据库很少被分隔开,而是存储成了一个整体,这样整块数据更加便于读写
4存储扩展这可能是两者之间最大的区别,关系型数据库是纵向扩展,也就是说想要提高处理能力,要使用速度更快的计算机。因为数据存储在关系表中, *** 作的性能瓶颈可能涉及到多个表,需要通过提升计算机性能来克服。虽然有很大的扩展空间,但是最终会达到纵向扩展的上限。而Nosql数据库是横向扩展的,它的存储天然就是分布式的,可以通过给资源池添加更多的普通数据库服务器来分担负载。
5查询方式关系型数据库通过结构化查询语言来 *** 作数据库(就是我们通常说的SQL)。SQL支持数据库CURD *** 作的功能非常强大,是业界的标准用法。而Nosql查询以块为单元 *** 作数据,使用的是非结构化查询语言(UnQl),它是没有标准的。关系型数据库表中主键的概念对应Nosql中存储文档的ID。关系型数据库使用预定义优化方式(比如索引)来加快查询 *** 作,而Nosql更简单更精确的数据访问模式。
6事务关系型数据库遵循ACID规则(原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)),而Nosql数据库遵循BASE原则(基本可用(Basically Availble)、软/柔性事务(Soft-state )、最终一致性(Eventual Consistency))。由于关系型数据库的数据强一致性,所以对事务的支持很好。关系型数据库支持对事务原子性细粒度控制,并且易于回滚事务。而Nosql数据库是在CAP(一致性、可用性、分区容忍度)中任选两项,因为基于节点的分布式系统中,很难全部满足,所以对事务的支持不是很好,虽然也可以使用事务,但是并不是Nosql的闪光点。
7性能关系型数据库为了维护数据的一致性付出了巨大的代价,读写性能比较差。在面对高并发读写性能非常差,面对海量数据的时候效率非常低。而Nosql存储的格式都是key-value类型的,并且存储在内存中,非常容易存储,而且对于数据的 一致性是 弱要求。Nosql无需sql的解析,提高了读写性能。
8授权方式大多数的关系型数据库都是付费的并且价格昂贵,成本较大(MySQL是开源的,所以应用的场景最多),而Nosql数据库通常都是开源的。
所以,在实际的应用环境中,我们一般会使用MySQL存储我们的业务过程中的数据,因为这些数据之间的关系比较复杂,我们常常会需要在查询一个表的数据时候,将其他关系表的数据查询出来,例如,查询某个用户的订单,那至少是需要用户表和订单表的数据。
查询某个商品的销售数据,那可能就会需要用户表,订单表,订单明细表,商品表等等。
而在这样的使用场景中,我们使用Redis来存储的话,也就是KeyValue形式存储的话,其实并不能满足我们的需要。
即使Redis的读取效率再高,我们也没法用。
但,对于某些没有关联少,且需要高频率读写,我们使用Redis就能够很好的提高整个体统的并发能力。
例如商品的库存信息,我们虽然在MySQL中会有这样的字段,但是我们并不想MySQL的数据库被高频的读写,因为使用这样会导致我的商品表或者库存表IO非常高,从而影响整个体统的效率。
所以,对于这样的数据,且有没有什么复杂逻辑关系(就只是隶属于SKU)的数据,我们就可以放在Redis里面,下单直接在Redis中减掉库存,这样,我们的订单的并发能力就能够提高了。
个人觉得应该站出来更正一下,相反的数据量大,更不应该用redis。
因为redis是内存型数据库啊,是放在内存里的。
设想一下,假如你的电脑100G的资料,都用redis来存储,那么你需要100G以上的内存!
使用场景Redis最明显的用例之一是将其用作缓存。只是保存热数据,或者具有过期的cache。
例如facebook,使用Memcached来作为其会话缓存。
总之,没有见过哪个大公司数据量大了,换掉mysql用redis的。
题主你错了,不是用redis代替MySQL,而是引入redis来优化。
BAT里越来越多的项目组已经采用了redis+MySQL的架构来开发平台工具。
如题主所说,当数据多的时候,MySQL的查询效率会大打折扣。我们通常默认如果查询的字段包含索引的话,返回是毫秒级别的。但是在实际工作中,我曾经遇到过一张包含10个字段的表,1800万+条数据,当某种场景下,我们不得不根据一个未加索引的字段进行精确查询的时候,单条sql语句的执行时长有时能够达到2min以上,就更别提如果用like这种模糊查询的话,其效率将会多么低下。
我们最开始是希望能够通过增加索引的方式解决,但是面对千万级别的数据量,我们也不敢贸然加索引,因为一旦数据库hang住,期间的所有数据库写入请求都会被放到等待队列中,如果请求是通过>
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)