java什么情况下使用redis redis什么时候要用事务

大家好，关于java什么情况下使用redis很多朋友都还不太明白，今天小编就来为大家分享关于redis什么时候要用事务的知识，希望对各位有所帮助！

数据多的时候为什么要使用redis而不用mysql

通常来说，当数据多、并发量大的时候，架构中可以引入Redis，帮助提升架构的整体性能，减少Mysql(或其他数据库)的压力，但不是使用Redis，就不用MySQL。

因为Redis的性能十分优越，可以支持每秒十几万此的读/写操作，并且它还支持持久化、集群部署、分布式、主从同步等，Redis在高并发的场景下数据的安全和一致性，所以它经常用于两个场景：

判断数据是否适合缓存到Redis中，可以从几个方面考虑：会经常查询么？命中率如何？写操作多么？数据大小？

我们经常采用这样的方式将数据刷到Redis中：查询的请求过来，现在Redis中查询，如果查询不到，就查询数据库拿到数据，再放到缓存中，这样第二次相同的查询请求过来，就可以直接在Redis中拿到数据；不过要注意【缓存穿透】的问题。

缓存的刷新会比较复杂，通常是修改完数据库之后，还需要对Redis中的数据进行操作；代码很简单，但是需要保证这两步为同一事务，或最终的事务一致性。

常见的就是计数器，比如一篇文章的阅读量，不可能每一次阅读就在数据库里面update一次。

高并发的场景很适合使用Redis，比如双11秒杀，库存一共就一千件，到了秒杀的时间，通常会在极为短暂的时间内，有数万级的请求达到服务器，如果使用数据库的话，很可能在这一瞬间造成数据库的崩溃，所以通常会使用Redis（秒杀的场景会比较复杂，Redis只是其中之一，例如如果请求超过某个数量的时候，多余的请求就会被限流）。

这种高并发的场景，是当请求达到服务器的时候，直接在Redis上读写，请求不会访问到数据库；程序会在合适的时间，比如一千件库存都被秒杀，再将数据批量写到数据库中。

所以通常来说，在必要的时候引入Redis，可以减少MySQL（或其他）数据库的压力，两者不是替代的关系。

Redis和MySQL的应用场景是不同的。

通常来说，没有说用Redis就不用MySQL的这种情况。

因为Redis是一种非关系型数据库（NoSQL），而MySQL是一种关系型数据库。

和Redis同类的数据库还有MongoDB和Memchache（其实并没有持久化数据）

那关系型数据库现在常用的一般有MySQL，SQL Server，Oracle。

我们先来了解一下关系型数据库和非关系型数据库的区别吧。

关系型数据库是表格式的，因此存储在表的行和列中。他们之间很容易关联协作存储，提取数据很方便。而Nosql数据库则与其相反，他是大块的组合在一起。通常存储在数据集中，就像文档、键值对或者图结构。

关系型数据库对应的是结构化数据，数据表都预先定义了结构（列的定义），结构描述了数据的形式和内容。这一点对数据建模至关重要，虽然预定义结构带来了可靠性和稳定性，但是修改这些数据比较困难。而Nosql数据库基于动态结构，使用与非结构化数据。因为Nosql数据库是动态结构，可以很容易适应数据类型和结构的变化。

关系型数据库的数据存储为了更高的规范性，把数据分割为最小的关系表以避免重复，获得精简的空间利用。虽然管理起来很清晰，但是单个操作设计到多张表的时候，数据管理就显得有点麻烦。而Nosql数据存储在平面数据集中，数据经常可能会重复。单个数据库很少被分隔开，而是存储成了一个整体，这样整块数据更加便于读写

这可能是两者之间最大的区别，关系型数据库是纵向扩展，也就是说想要提高处理能力，要使用速度更快的计算机。因为数据存储在关系表中，操作的性能瓶颈可能涉及到多个表，需要通过提升计算机性能来克服。虽然有很大的扩展空间，但是最终会达到纵向扩展的上限。而Nosql数据库是横向扩展的，它的存储天然就是分布式的，可以通过给资源池添加更多的普通数据库服务器来分担负载。

关系型数据库通过结构化查询语言来操作数据库（就是我们通常说的SQL）。SQL支持数据库CURD操作的功能非常强大，是业界的标准用法。而Nosql查询以块为单元操作数据，使用的是非结构化查询语言（UnQl），它是没有标准的。关系型数据库表中主键的概念对应Nosql中存储文档的ID。关系型数据库使用预定义优化方式（比如索引）来加快查询操作，而Nosql更简单更精确的数据访问模式。

关系型数据库遵循ACID规则（原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)），而Nosql数据库遵循BASE原则（基本可用（Basically Availble）、软/柔性事务（Soft-state）、最终一致性（Eventual Consistency））。由于关系型数据库的数据强一致性，所以对事务的支持很好。关系型数据库支持对事务原子性细粒度控制，并且易于回滚事务。而Nosql数据库是在CAP（一致性、可用性、分区容忍度）中任选两项，因为基于节点的分布式系统中，很难全部满足，所以对事务的支持不是很好，虽然也可以使用事务，但是并不是Nosql的闪光点。

关系型数据库为了维护数据的一致性付出了巨大的代价，读写性能比较差。在面对高并发读写性能非常差，面对海量数据的时候效率非常低。而Nosql存储的格式都是key-value类型的，并且存储在内存中，非常容易存储，而且对于数据的一致性是弱要求。Nosql无需sql的解析，提高了读写性能。

大多数的关系型数据库都是付费的并且价格昂贵，成本较大（MySQL是开源的，所以应用的场景最多），而Nosql数据库通常都是开源的。

所以，在实际的应用环境中，我们一般会使用MySQL存储我们的业务过程中的数据，因为这些数据之间的关系比较复杂，我们常常会需要在查询一个表的数据时候，将其他关系表的数据查询出来，例如，查询某个用户的订单，那至少是需要用户表和订单表的数据。

查询某个商品的销售数据，那可能就会需要用户表，订单表，订单明细表，商品表等等。

而在这样的使用场景中，我们使用Redis来存储的话，也就是KeyValue形式存储的话，其实并不能满足我们的需要。

即使Redis的读取效率再高，我们也没法用。

但，对于某些没有关联少，且需要高频率读写，我们使用Redis就能够很好的提高整个体统的并发能力。

例如商品的库存信息，我们虽然在MySQL中会有这样的字段，但是我们并不想MySQL的数据库被高频的读写，因为使用这样会导致我的商品表或者库存表IO非常高，从而影响整个体统的效率。

所以，对于这样的数据，且有没有什么复杂逻辑关系（就只是隶属于SKU）的数据，我们就可以放在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住，期间的所有数据库写入请求都会被放到等待队列中，如果请求是通过http请求发过来的，很有可能导致服务发生分钟级别的超时不响应。

经过一番调研，最终敲定的解决方案是引入redis作为缓存。redis具有运行效率高，数据查询速度快，支持多种存储类型以及事务等优势，我们把经常读取，而不经常改动的数据放入redis中，服务器读取这类数据的时候时候，直接与redis通信，极大的缓解了MySQL的压力。

然而，我在上面也说了，是redis+MySQL结合的方式，而不是替代。原因就是redis虽然读写很快，但是不适合做数据持久层，主要原因是使用redis做数据落盘是要以效率作为代价的，即每隔制定的时间，redis就要去进行数据备份/落盘，这对于单线程的它来说，势必会因“分心”而影响效率，结果得不偿失。

楼主你好，首先纠正下，数据多并不是一定就用Redis，Redis归属于NoSQL数据库中，其特点拥有高性能读写数据速度，主要解决业务效率瓶颈。下面就详细说下Redis的相比MySQL优点。（关于Redis详细了解参见我近期文章：https://www.toutiao.com/i6543810796214813187/）

Redis非常快，每秒可执行大约10万次的读写速度。

Redis支持丰富的数据类型，有二进制字符串、列表、集合、排序集和散列等等。这使得Redis很容易被用来解决各种问题，因为我们知道哪些问题可以更好使用地哪些数据类型来处理解决。

Redis的所有操作都是原子操作，这确保如果两个客户端并发访问，Redis服务器能接收更新的值。

Redis支持主从复制的配置，它可以实现主服务器的完全拷贝。

以上为开发者青睐Redis的主要几个可取之处。但是，请注意实际生产环境中企业都是结合Redis和MySQL的特定进行不同应用场景的取舍。如缓存——热数据、计数器、消息队列（与ActiveMQ，RocketMQ等工具类似）、位操作（大数据处理）、分布式锁与单线程机制、最新列表（如新闻列表页面最新的新闻列表）以及排行榜等等可以看见Redis大显身手的场景。可是对于严谨的数据准确度和复杂的关系型应用MySQL等关系型数据库依然不可替。

web应用中一般采用MySQL+Redis的方式，web应用每次先访问Redis，如果没有找到数据，才去访问MySQL。

1、mysql：数据放在磁盘 redis：数据放在内存。

首先要知道mysql存储在磁盘里，redis存储在内存里，redis既可以用来做持久存储，也可以做缓存，而目前大多数公司的存储都是mysql+ redis，mysql作为主存储，redis作为辅助存储被用作缓存，加快访问读取的速度，提高性能。

1、mysql支持sql查询，可以实现一些关联的查询以及统计；

2、redis对内存要求比较高，在有限的条件下不能把所有数据都放在redis；

3、mysql偏向于存数据，redis偏向于快速取数据，但redis查询复杂的表关系时不如mysql，所以可以把热门的数据放redis，mysql存基本数据。

mysql作为持久化存储的关系型数据库，相对薄弱的地方在于每次请求访问数据库时，都存在着I/O操作，如果反复频繁的访问数据库。第一：会在反复链接数据库上花费大量时间，从而导致运行效率过慢；第二：反复地访问数据库也会导致数据库的负载过高，那么此时缓存的概念就衍生了出来。

由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。

redis是放在内存的~！

数据量多少绝对不是选择redis和mysql的准则，因为无论是mysql和redis都可以集群扩展，约束它们的只是硬件(即你有没有那么多钱搭建上千个组成的集群)，我个人觉得数据读取的快慢可能是选择的标准之一，另外工作中往往是两者同是使用，因为mysql存储在硬盘，做持久化存储，而redis存储在内存中做缓存提升效率。

关系型数据库是必不可少的，因为只有关系型数据库才能提供给你各种各样的查询方式。如果有一系列的数据会频繁的查询，那么就用redis进行非持久化的存储，以供查询使用，是解决并发性能问题的其中一个手段

Java工程师是如何使用Redis的

redis算是用的最多的key-value型缓存组件了！

因为使用了key-value型，所以存取效率极好，简单来说就类似JAVA中的hashMap，不过是用整个服务器内存来当做map，但是redis的数据可以通过配置指令保存到硬盘(同步保存save，异步保存bgsave)！

redis是单线程模式，这能保证redis中存取的数据库绝对线程安全，同时，因为避免多线程之间切换的开销，redis的存取性能跟使用多线程的memcache在一定程度上旗鼓相当，都非常高的性能，不过redis的value支持G级别的数据，能用来存放大文本等，这是memcache不能做到的。。

为了进一步提升redis的稳定性和存取性能，redis支持集群，具体搭建方式，可参考我之前的一篇回答！

那么redis在实际的开发中，主要用来做什么呢？

1，数据存取:无需多说！

2，加锁:因为redis是单线程的，提供的比如incr，setnx等方法均可以用来当做锁使用！

3，秒杀系统:商品存队列，请求进来进行匹配，然后异步出单即可！

4，计数器:对同一个key的value计数即可！

5，超时问题:比如页面访问超时啥的，页面访问接口的时候持续更新某个设定值，超过某个时间段再访问，则超时！

当然，redis在使用过程中会存在持久化失败，缓存击穿，扩容困难等问题，不过无论如何，redis都是一款最值得用的缓存工具！

使用过程中有任何问题，欢迎大家一起交流，redis还有什么遗漏功能，也请大家补充，谢谢！

redis什么时候要用事务

Redis事务使用总结：

Redis的事务机制允许同时执行多条指令，它是原子性操作，事务中的命令要么全部执行，要么全部不执行，另外，事务中的所有指令都会被序列化，而且其开始执行过程中，不回被即时过来的指令所打断，其需要经历三个过程，分别为开始事务、命令入队以及执行事务。

·相关命令

·如何使用

·脚本事务

·遇到问题

·例子演示

一、相关命令

1、MULTI

该命令用来开启事务，它总是返回ok结果，当其执行之后，客户端可以继续发送任意条数量的指令，这些指令不会立即被执行，而是被放到了队列中，直到EXEC被调用之后，所有命令才会被序列化执行。

2、EXEC

该命令负责触发并执行队列中所有的命令。

NOTE:

如果MULTI开启之后，因为某些原因没有成功执行EXEC，那么事务中所有的命令都不会被执行的。

3、DISCARD

该命令用来刷新事务中所有排队等待执行的指令，它总是返回ok结果，并且将服务连接状态恢复到正常。如果已经使用WATCH，那么其会将释放所有被WATCH的key。

4、WATCH

标记所有指定的key被监控起来，使其在事务中有条件的执行（乐观锁）。

NOTE:

A、WATCH使得EXEC命令需要有条件的执行，也就是事务只能在所有被监视的键没有被修改的前提下才能执行。另外，在EXEC被执行之后，所有的WATCH都会被取消。

B、UNWATCH手动取消对所有键的WATCH，如果执行了EXEC或者DISCARD，则不需要手动执行UNWATCH命令。

二、如何使用

Redis原生使用(Redis-cli)：

127.0.0.1:6379> multi//事务开始的动作标志下面即为入队

OK

127.0.0.1:6379> set book-name"Thinking in Java"

QUEUED

127.0.0.1:6379> get book-name

QUEUED

127.0.0.1:6379> sadd tag"java""Programming""Thinking"

QUEUED

127.0.0.1:6379> smembers tag

QUEUED

127.0.0.1:6379> exec//执行事务

1) OK

2)"Thinking in Java"

3)(integer) 3

4) 1)"Thinking"

2)"Programming"

3)"java"

127.0.0.1:6379> discard//事务已执行完毕已经自动取消

(error) ERR DISCARD without MULTI

127.0.0.1:6379> multi

OK

127.0.0.1:6379> set book-name"Patterns in Java"

QUEUED

127.0.0.1:6379> get book-name

QUEUED

127.0.0.1:6379> sadd tag"Java""Thinking""Programming"

QUEUED

127.0.0.1:6379> smembers tag

QUEUED

127.0.0.1:6379> discard//事务未执行可以刷新队列指令状态取消执行

OK

127.0.0.1:6379> exec//事务已经被取消不能再执行

(error) ERR EXEC without MULTI

三、脚本事务

Redis 2.6开始支持了脚本，而该脚本本身就是一种事务机制，所以任何在事务里可以完成的事，在脚本里面也能完成，并且使用脚本更简单些，并且速度也更快。不过因为事务提供了一种即使不使用脚本，也可以避免竞争条件的方法，并且事务本身的实现并不复杂，所以现在的使用也比较多，但不排除日后可能被替代或是占据主要地位的可能。

NOTE：

Redis为什么引入两种处理事务的方式？脚本功能是 Redis 2.6才引入的，而事务功能则在更早之前就存在，所以 Redis才会同时存在两种处理事务的方法。另外，事务脚本会在后续文章中总结介绍。

四、遇到问题

1、乐观锁实现

举个例子，假设我们需要原子性为某个键加1操作（假设INCR不存在），那么应该是这样的执行语句：

SET mykey 1

val= GET mykey

val= val+ 1

SET mykey${val}

单个客户端访问操作没有任何问题，如果是多个客户端同时访问mykey，就会产生资源共享访问问题，比如：现在有个两个客户端访问同一个键mykey，那么mykey的可能是2，但是我们期望的值应该是3才对，这个类似于高并发下的sync锁机制，所以我们需要使用WATCH来监控被共享的键mykey，如下：

WATCH mykey（可监控多个键）

val= GET mykey

val= val+ 1

MULTI

SET mykey${val}

EXEC

NOTE：

虽然大多情况下，多个客户端访问操作同一个键的情况很少或没有，但是不能排除这个特殊情况，所以建议在有可能产生键共享的指令中使用WATCH在EXEC执行前对其监管。

2、Redis不支持回滚(Roll Back)

Redis的事务不支持回滚，这点不同于关系数据库中的事务，所以它的内部保持了简单且快速的特点。另外，Redis不支持回滚是这样考虑的：Redis事务中命令之所以会失败，是由于错误的编程所造成，通过事务回滚是不能回避这个根本问题。

NOTE：

Redis事务中命令执行失败，仍会继续执行后面的执行，在没有特殊干预前提下，直到执行完队列中所有指令为止。

3、使用事务可能遇到的问题

A、事务在执行EXEC之前，入队的命令可能会出错，举个例子：命令可能会产生语法错误（参数数量错误，参数名错误等），或者其他更严重的错误，比如内存不足（如果服务器使用maxmemory设置了最大内存限制的话）。

B、事务在执行EXEC之前，举个例子：事务中的命令可能处理了错误类型的键，比如将列表命令用在了字符串键上面等。

对于发生在EXEC执行之前的错误，客户端以前的做法是检查命令入队所得的返回值：如果命令入队时返回QUEUED，那么入队成功；否则，就是入队失败。如果有命令在入队时失败，那么大部分客户端都会停止并取消这个事务。

从 Redis 2.6.5开始，服务器会对命令入队失败的情况进行记录，并在客户端调用EXEC命令时，拒绝执行并自动放弃这个事务。

在 Redis 2.6.5以前， Redis只执行事务中那些入队成功的命令，而忽略那些入队失败的命令。而新的处理方式则使得在管道技术中包含事务变得简单，因为发送事务和读取事务的回复都只需要和服务器进行一次通讯即可。

至于那些在EXEC命令执行之后所产生的错误，并没有对它们进行特别处理：即使事务中有某个/某些命令在执行时产生了错误，事务中的其他命令仍然会继续执行。

五、例子演示

<?php

$redis=new\Redis();

$redis->connect('127.0.0.1',6379);

$result=array();

//开启事务

$redis->multi();

//添加指令到队列

$redis->set('book-name','Thinking in PHP!');

$redis->sAdd('tags','PHP','Programming','Thinking');

$bookname=$redis->get('book-name');

$tags=$redis->sMembers('tags');

//执行事务

$redis->exec();

//显示结果

echo'书名：'.$bookname.'标签：'.$tags;

?>

结果：

关于本次java什么情况下使用redis和redis什么时候要用事务的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。