简介

本来对这个Redis没什么兴趣的，不就是一个缓存的数据库而已吗？直到上次配置spring-redis的时候，发现这个东西没有用户名。

spring:
  redis:
    host: 127.0.0.1
    port: 6379
    password:

配置如上所示，只有主机、端口和密码，和普通的MySQL或其他数据库不同。

Redis是一个使用ANSI C编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。

我们熟知的就是Redis的缓存，Redis采用C编写，运行异常的快。是有磁盘存储支持的内存数据库！

适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。

使用场景：股票价格、数据分析、实时数据搜集、实时通讯。

NoSQL

Redis属于NoSQL，NoSQL = Not Only SQL。

如今数据量越来越大，传统的关系型数据库已经无法应付如此大数据的需求了。

举个例子：假设我们使用关系型数据库存储朋友圈，那一天会产生多少数据？再查询的时候数据库不就死了吗？

这让我想起了我之前关注的一个帖子：腾讯微信的后台数据库到底是怎么设计的？无知的人相谈甚欢，最后好像是官方的哥们是在看不下去了，回复：谁告诉你们微信用的是关系型数据库？

普通关系型数据库，如果只查询的话效率很高？如果算上读写的话？那可能传统的数据库都承受不住高并发。

重要的是关系型数据库没法扩展，大家想一想，因为数据之间是有关系的，所以数据库扩展绝对不像扩展后台服务规模一样再拎个服务器出来那么简单。

由此可见，在数据量日渐增长的今天，为了解决大数据量与高并发的难题，NoSQL应运而生。

NoSQL产品主要有四类：

这些数据库的名称大家或多或少应该听说过吧？今天才真正知道它们的作用，各有其特长，我们需根据业务场景动态选择。Facebook的消息存储采用的就是HBase数据库，支持大数据进行随机、实时访问。

NoSQL因为数据之间都是没有关系的，所以易扩展，同时具有很高的读写性能，很适合高并发场景。

历史

2008年，意大利的一家创业公司Merzia推出了一款基于MySQL的网站实时统计系统LLOOGG。

没过多久，创始人Salvatore Sanfilippo对MySQL的性能大失所望，于是他决定自己写一个数据库。牛人就是牛人，我们就算质疑MySQL的性能，想写也写不出来啊？！

2009年，Salvatore Sanfilippo完成了数据库的编写，这就是Redis。

Salvatore Sanfilippo将Redis开源，并一直进行着Redis的开发，直到今天。我们熟知的Github、StackOverflow、新浪微博等公司都是Redis的用户。

缓存

传统的缓存代码需要这样写，很冗长，都是重复的代码。

ValueOperations<String, String> valueOperations = redisTemplate.opsForValue();

logger.info("判断Redis中是否有Key");
if (redisTemplate.hasKey(url)) {
    logger.info("Redis命中，从Redis中获取");
    return valueOperations.get(url);
}

logger.info("发起Get请求");
ResponseEntity<String> response = restTemplate.getForEntity(url, String.class);

logger.info("存入缓存");
valueOperations.set(url, response.getBody(), TIME_OUT, TimeUnit.MINUTES);

感谢Spring AOP，我们可以使用注解实现缓存功能。

@Cacheable("cacheName")
public List<Student> findAll() {
    return studentRepository.findAll();
}

使用注解实现缓存很简单，同时@Cacheable还有许多的高级用法，以后与大家详述。

操作

Redis有三种动作：

GET：根据键查找值。

SET：给定键存储值。

DEL：删除键中的值。

然后就是Redis的数据结构，这个觉得暂时还不需要知道，毕竟现在使用的是现成的@Cacheable注解，还不需要我们手动去操作Redis。

一如代码深似海，软件之路很广很远。生命有限的我们不能把所有东西都精通，我们要在学习成本与能力提升之间进行权衡。

来自：https://segmentfault.com/a/1190000018930546

链接: https://www.fly63.com/article/detial/2965