内存数据库有现成的redis，高效存取键值对，键设为你的查询条件，值设为你的查询结果转为字符串
创新互联从2013年创立，是专业互联网技术服务公司，拥有项目网站建设、成都网站制作网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元宿松做网站,已为上家服务,为宿松各地企业和个人服务,联系电话:18982081108
查询时先从redis取，没有再查数据库，并且设置redis的过期时间，这种方式需要项目对实时性要求不高，这样你才能用缓存，而且如果你的项目没有明显的热点，即没有某些内容确定会多次被查到，那你缓存就不会命中，添加缓存反而影响你得速度
redis是一种nosql的内存数据库，感兴趣你可以了解一下，优点就是性能强劲
数据查询请求多就把结果缓存下来，你查数据库再快也没有直接把结果从内存读出来快
同样的sql请求只有第一次查数据库，之后通通读内存
或者你干脆借助这种思想，创建一个全局的map对象，然后查询条件作key
，结果作value，就省去了了解redis的过程，把整个数据库装内存不太科学，你有多少条数据啊
一般将NoSQL数据库分为四大类：键值(Key-Value)存储数据库、列存储数据库、文档型数据库和图形(Graph)数据库。它们的数据模型、优缺点、典型应用场景。
键值(Key-Value)存储数据库Key指向Value的键值对，通常用hash表来实现查找速度快数据无结构化(通常只被当作字符串或者二进制数据)内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等。
列存储数据库，以列簇式存储，将同一列数据存在一起查找速度快，可扩展性强，更容易进行分布式扩展功能相对局限分布式的文件系统。
文档型数据库，Key-Value对应的键值对，Value为结构化数据，数据结构要求不严格，表结构可变(不需要像关系型数据库一样需预先定义表结构)，查询性能不高，而且缺乏统一的查询语法，Web应用。
图形(Graph)数据库，图结构，利用图结构相关算法(如最短路径寻址，N度关系查找等)，很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案，社交网络，推荐系统等。
redis是一个单线程的NoSQL数据库，主要用来做数据缓存，一般大型网站的应用和数据库之间的那一层就是Redis。比如京东商城的页面查找功能，用户接触到的查询的第一层就是Redis数据缓存层，缓存中找不到的数据，再进入数据库查询。Redis中缓存热点数据，能够保护数据库，提高查询效率。
NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在处理web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，出现了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，特别是大数据应用难题。
内存数据库，也叫缓存，可以存储访问频次很高的数据
redis是一个nosql(not only sql不仅仅只有sql)数据库，翻译成中文叫做非关系型型数据库
早期需要延迟处理的业务场景，更多的是通过定时任务扫表，然后执行满足条件的记录，具有频率高、命中低、资源消耗大的缺点。随着消息中间件的普及，延迟消息可以很好的处理这种场景，本文主要介绍延迟消息的使用场景以及基于常见的消息中间件如何实现延迟队列，最后给出了一个在网易公开课使用延迟队列的实践。
1、有效期：限时活动、拼团。。。
2、超时处理：取消超时未支付订单、超时自动确认收货。。。
4、重试：网络异常重试、打车派单、依赖条件未满足重试。。。
5、定时任务：智能设备定时启动。。。
1、RabbitMQ
1）简介：基于AMQP协议，使用Erlang编写，实现了一个Broker框架
a、Broker：接收和分发消息的代理服务器
b、Virtual Host：虚拟主机之间相互隔离，可理解为一个虚拟主机对应一个消息服务
c、Exchange：交换机，消息发送到指定虚拟机的交换机上
d、Binding：交换机与队列绑定，并通过路由策略和routingKey将消息投递到一个或多个队列中
e、Queue：存放消息的队列，FIFO，可持久化
f、Channel：信道，消费者通过信道消费消息，一个TCP连接上可同时创建成百上千个信道，作为消息隔离
2）延迟队列实现：RabbitMQ的延迟队列基于消息的存活时间TTL（Time To Live）和死信交换机DLE（Dead Letter Exchanges）实现
a、TTL：RabbitMQ支持对队列和消息各自设置存活时间，取二者中较小的值，即队列无消费者连接或消息在队列中一直未被消费的过期时间
b、DLE：过期的消息通过绑定的死信交换机，路由到指定的死信队列，消费者实际上消费的是死信队列上的消息
3）缺点：
a、配置麻烦，额外增加一个死信交换机和一个死信队列的配置
b、脆弱性，配置错误或者生产者消费者连接的队列错误都有可能造成延迟失效
2、RocketMQ
1）简介：来源于阿里，目前为Apache顶级开源项目，使用Java编写，基于长轮询的拉取方式，支持事务消息，并解决了顺序消息和海量堆积的问题
a、Broker：存放Topic并根据读取Producer的提交日志，将逻辑上的一个Topic分多个Queue存储，每个Queue上存储消息在提交日志上的位置
b、Name Server：无状态的节点，维护Topic与Broker的对应关系以及Broker的主从关系
2）延迟队列实现：RocketMQ发送延时消息时先把消息按照延迟时间段发送到指定的队列中(rocketmq把每种延迟时间段的消息都存放到同一个队列中)，然后通过一个定时器进行轮训这些队列，查看消息是否到期，如果到期就把这个消息发送到指定topic的队列中
3）缺点：延迟时间粒度受限制（1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h）
3、Kafka
1）简介：来源于Linkedin，目前为Apache顶级开源项目，使用Scala和Java编写，基于zookeeper协调的分布式、流处理的日志系统，升级版为Jafka
2）延迟队列实现：Kafka支持延时生产、延时拉取、延时删除等，其基于时间轮和JDK的DelayQueue实现
a、时间轮(TimingWheel)：是一个存储定时任务的环形队列，底层采用数组实现，数组中的每个元素可以存放一个定时任务列表
b、定时任务列表(TimerTaskList)：是一个环形的双向链表，链表中的每一项表示的都是定时任务项
c、定时任务项(TimerTaskEntry)：封装了真正的定时任务TimerTask
d、层级时间轮：当任务的到期时间超过了当前时间轮所表示的时间范围时，就会尝试添加到上层时间轮中，类似于钟表就是一个三级时间轮
e、JDK DelayQueue：存储TimerTaskList，并根据其expiration来推进时间轮的时间，每推进一次除执行相应任务列表外，层级时间轮也会进行相应调整
3）缺点：
a、延迟精度取决于时间格设置
b、延迟任务除由超时触发还可能被外部事件触发而执行
4、ActiveMQ
1）简介：基于JMS协议，Java编写的Apache顶级开源项目，支持点对点和发布订阅两种模式。
a、点对点（point-to-point）：消息发送到指定的队列，每条消息只有一个消费者能够消费，基于拉模型
b、发布订阅（publish/subscribe）：消息发送到主题Topic上，每条消息会被订阅该Topic的所有消费者各自消费，基于推模型
2）延迟队列实现：需要延迟的消息会先存储在JobStore中，通过异步线程任务JobScheduler将到达投递时间的消息投递到相应队列上
a、Broker Filter：Broker中定义了一系列BrokerFilter的子类构成拦截器链，按顺序对消息进行相应处理
b、ScheduleBroker：当消息中指定了延迟相关属性，并且jobId为空时，会生成调度任务存储到JobStore中，此时消息不会进入到队列
c、JobStore：基于BTree存储，key为任务执行的时间戳，value为该时间戳下需要执行的任务列表
d、JobScheduler：取JobStore中最小的key执行（调度时间最早的），执行时间=当前时间，将该任务列表依次投递到所属的队列，对于需要重复投递和投递失败的会再次存入JobStore中。
注： 此处JobScheduler的执行时间间隔可动态变化，默认0.5s，有新任务时会立即执行（Object-notifyAll()）并设置时间间隔为0.1s，没有新任务后，下次执行时间为最近任务的调度执行时间。
3）缺点：投递到队列失败，将消息重新存入JobStore，消息调度执行时间=系统当前时间+延迟时间，会导致消息被真实投递的时间可能为设置的延迟时间的整数倍
5、Redis
1）简介：基于Key-Value的NoSQL数据库，由于其极高的性能常被当作缓存来使用，其数据结构支持：字符串、哈希、列表、集合、有序集合
2）延迟队列实现：Redis的延迟队列基于有序集合，score为执行时间戳，value为任务实体或任务实体引用
3）缺点：
a、实现复杂，本身不支持
b、完全基于内存，延迟时间长浪费内存资源
6、消息队列对比
1、公开课延迟队列技术选型
1）业务场景：关闭超时未支付订单、限时优惠活动、拼团
2）性能要求：订单、活动、拼团 数据量可控，上述MQ均能满足要求
3）可靠性：使用ActiveMQ、RabbitMQ、RocketMQ作为延迟队列更普遍
4）可用性：ActiveMQ、RocketMQ自身支持延迟队列功能，且目前公开课业务中使用的中间件为ActiveMQ和Kafka
5）延迟时间灵活：活动的开始和结束时间比较灵活，而RocketMQ时间粒度较粗，Kafka会依赖时间格有精度缺失
结论： 最终选择ActiveMQ来作为延迟队列
2、业务场景：关闭未支付订单
1）关闭微信未支付订单
2）关闭IOS未支付订单
3、ActiveMQ使用方式
1）activemq.xml中支持调度任务
2）发送消息时，设置message的延迟属性
其中：
a、延迟处理
AMQ_SCHEDULED_DELAY：设置多长时间后，投递给消费者（毫秒）
b、重复投递
AMQ_SCHEDULED_PERIOD：重复投递时间间隔（毫秒）
AMQ_SCHEDULED_REPEAT：重复投递次数
c、指定调度计划
AMQ_SCHEDULED_CRON：corn正则表达式
4、公开课使用中进行的优化
1）可靠性：针对实际投递时间可能翻倍的问题，结合ActiveMQ的重复投递，在消费者逻辑中做幂等处理来保证延迟时间的准确性
2）可追溯性：延迟消息及消费情况做数据库冗余存储
3）易用性：业务上定义好延迟枚举类型，直接使用JmsDelayTemplate发送，无需关心数据备份和参数等细节
1、无论是基于死信队列还是基于数据先存储后投递，本质上都是将延迟待发送的消息数据与正常订阅的队列分开存储，从而降低耦合度
2、无论是检查队头消息TTL还是调度存储的延迟数据，本质上都是通过定时任务来完成的，但是定时任务的触发策略以及延迟数据的存储方式决定了不同中间件之间的性能优劣
张浩，2018年加入网易传媒，高级Java开发工程师，目前在网易公开课主要做支付财务体系、版本迭代相关的工作。
NoSQL(NoSQL
=
Not
Only
SQL
)，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。
随着大数据的不断发展，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。现今的计算机体系结构在数据存储方面要有庞大的水平扩展性，而NoSQL也正是致力于改变这一现状。目前Google的
BigTable和Amazon
的Dynamo使用的就是NoSQL型数据库，本文介绍了10种出色的NoSQL数据库。
虽然NoSQL流行语火起来才短短一年的时间，但是不可否认，现在已经开始了第二代运动。尽管早期的堆栈代码只能算是一种实验，然而现在的系统已经更加的成熟、稳定。不过现在也面临着一个严酷的事实：技术越来越成熟——以至于原来很好的NoSQL数据存储不得不进行重写，也有少数人认为这就是所谓的2.0版本。这里列出一些比较知名的NoSQL工具，可以为大数据建立快速、可扩展的存储库。
给一个地址吧