NoSQL被我们用得最多的当数key-value存储,当然还有其他的文档型的、列存储、图型数据库、xml数据库等.在NoSQL概念提出之前,这些数据库就被用于各种系统当中,但是却很少用于web互联网应用.比如cdb、qdbm、bdb数据库.
传统关系数据库的瓶颈
传统的关系数据库具有不错的性能,高稳定型,久经历史考验,而且使用简单,功能强大,同时也积累了大量的成功案例.在互联网领域,MySQL成为了绝对靠前的王者,毫不夸张的说,MySQL为互联网的发展做出了卓越的贡献.
到了最近10年,网站开始快速发展.火爆的论坛、博客、sns、微博逐渐引领web领域的潮流.在初期,论坛的流量其实也不大,如果你接触网络比较早,你可能还记得那个时候还有文本型存储的论坛程序,可以想象一般的论坛的流量有多大.
Memcached+MySQL
后来,随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题,web程序不再仅仅专注在功能上,同时也在追求性能.程序员们开始大量的使用缓存技术来缓解数据库的压力,优化数据库的结构和索引.开始比较流行的是通过文件缓存来缓解数据库压力,但是当访问量继续增大的时候,多台web机器通过文件缓存不能共享,大量的小文件缓存也带了了比较高的IO压力.在这个时候,Memcached就自然的成为一个非常时尚的技术产品.
Memcached作为一个独立的分布式的缓存服务器,为多个web服务器提供了一个共享的高性能缓存服务,在Memcached服务器上,又发展了根据hash算法来进行多台Memcached缓存服务的扩展,然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端.当时,如果你去面试,你说你有Memcached经验,肯定会加分的.
Mysql主从读写分离
由于数据库的写入压力增加,Memcached只能缓解数据库的读取压力.读写集中在一个数据库上让数据库不堪重负,大部分网站开始使用主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性.Mysql的master-slave模式成为这个时候的网站标配了.
MySQL的扩展性瓶颈
在互联网,大部分的MySQL都应该是IO密集型的,事实上,如果你的MySQL是个CPU密集型的话,那么很可能你的MySQL设计得有性能问题,需要优化了.大数据量高并发环境下的MySQL应用开发越来越复杂,也越来越具有技术挑战性.分表分库的规则把握都是需要经验的.虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性,但是避免不了整个架构的复杂性.分库分表的子库到一定阶段又面临扩展问题.还有就是需求的变更,可能又需要一种新的分库方式.
关系数据库很强大,但是它并不能很好的应付所有的应用场景.MySQL的扩展性差（需要复杂的技术来实现）,大数据下IO压力大,表结构更改困难,正是当前使用MySQL的开发人员面临的问题.
NOSQL的优势易扩展NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性.数据之间无关系,这样就非常容易扩展.也无形之间,在架构的层面上带来了可扩展的能力.
大数据量,高性能
灵活的数据模型
高可用NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构.比如Cassandra,HBase模型,通过复制模型也能实现高可用.
总结NoSQL数据库的出现,弥补了关系数据（比如MySQL）在某些方面的不足,在某些方面能极大的节省开发成本和维护成本.
NewSQL是对一类现代关系型数据库的统称,这类数据库对于一般的OLTP读写请求提供可横向扩展的性能,同时支持事务的ACID保证.这些系统既拥有NoSQL数据库的扩展性,又保持传统数据库的事务特性.NewSQL重新将"应用程序逻辑与数据操作逻辑应该分离"的理念带回到现代数据库的世界,这也验证了历史的发展总是呈现出螺旋上升的形式.
NoSQL的拥趸普遍认为阻碍传统数据库横向扩容、提高可用性的原因在于ACID保证和关系模型,所以呢NoSQL运动的核心就是放弃事务强一致性以及关系模型,拥抱最终一致性和其它数据模型?(如 key/value,graphs 和Documents).
两个最著名的NoSQL数据库就是Google的BigTable和Amazon的Dynamo,由于二者都未开源,其它组织就开始推出类似的开源替代项目,包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable).有一些创业公司也加入到这场NoSQL运动中,它们不一定是受BigTable和Dynamo的启发,但都响应了NoSQL的哲学,其中最出名的就是MongoDB.
一些组织,如Google,已经发现他们的许多工程师将过多的精力放在处理数据一致性上,这既暴露了数据库的抽象、又提高了代码的复杂度,这时候要么选择回到传统DBMS时代,用更高的机器配置纵向扩容,要么选择回到中间件时代,开发支持分布式事务的中间件.这两种方案成本都很高,于是NewSQL运动开始酝酿.
NewSQL数据库设计针对的读写事务有以下特点：
①.、耗时短.
也有一些学者认为NewSQL系统是特指实现上使用Lock-free并发控制技术和share-nothing架构的数据库.所有我们认为是NewSQL的数据库系统确实都有这样的特点.
传统数据库仍旧会有一席之地,至于NewSQL的优势又是什么,简单和大家说说：
首先关于"中间件+关系数据库分库分表"算不算NewSQL分布式数据库问题,国外有篇论文pavlo-newsql-sigmodrec,如果根据该文中的分类,Spanner、TiDB、OB算是第一种新架构型,Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种（文中还有第三种云数据库,本文暂不详细介绍）.
基于中间件（包括SDK和Proxy两种形式）+传统关系数据库（分库分表）模式是不是分布式架构?我觉得是的,因为存储确实也分布式了,也能实现横向扩展.但是不是"伪"分布式数据库?从架构先进性来看,这么说也有一定道理.
"伪"主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等,这在分布式数据库架构中实际上冗余低效的.为了避免引起真伪分布式数据库的口水战,本文中NewSQL数据库特指这种新架构NewSQL数据库.
NewSQL数据库相比中间件+分库分表的先进在哪儿?画一个简单的架构对比图：
传统数据库面向磁盘设计,基于内存的存储管理及并发控制,不如NewSQL数据库那般高效利用；
中间件模式SQL解析、执行计划优化等在中间件与数据库中重复工作,效率相比较低；
NewSQL数据库的分布式事务相比于XA进行了优化,性能更高；
NewSQL数据库天生支持数据分片,数据的迁移、扩容都是自动化的,大大减轻了DBA的工作,同时对应用透明,无需在SQL指定分库分表键.
在大数据时代,"多种架构支持多类应用"成为数据库行业应对大数据的基本思路,数据库行业出现互为补充的三大阵营,适用于事务处理应用的OldSQL、适用于数据分析应用的NewSQL和适用于互联网应用的NoSQL.但在一些复杂的应用场景中,单一数据库架构都不能完全满足应用场景对海量结构化和非结构化数据的存储管理、复杂分析、关联查询、实时性处理和控制建设成本等多方面的需要,所以呢不同架构数据库混合部署应用成为满足复杂应用的必然选择.不同架构数据库混合使用的模式可以概括为：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三种主要模式.下面通过三个案例对不同架构数据库的混合应用部署进行介绍.
OldSQL+NewSQL 在数据中心类应用中混合部署
采用OldSQL+NewSQL模式构建数据中心,在充分发挥OldSQL数据库的事务处理能力的同时,借助NewSQL在实时性、复杂分析、即席查询等方面的独特优势,以及面对海量数据时较强的扩展能力,满足数据中心对当前"热"数据事务型处理和海量历史"冷"数据分析两方面的需求.OldSQL+NewSQL模式在数据中心类应用中的互补作用体现在,OldSQL弥补了NewSQL不适合事务处理的不足,NewSQL弥补了OldSQL在海量数据存储能力和处理性能方面的缺陷.
商业银行数据中心采用OldSQL+NewSQL混合部署方式搭建,OldSQL数据库满足各业务系统数据的归档备份和事务型应用,NewSQL MPP数据库集群对即席查询、多维分析等应用提供高性能支持,并且通过MPP集群架构实现应对海量数据存储的扩展能力.
商业银行数据中心存储架构
OldSQL+NoSQL 在互联网大数据应用中混合部署
在互联网大数据应用中采用OldSQL+NoSQL混合模式,能够很好的解决互联网大数据应用对海量结构化和非结构化数据进行存储和快速处理的需求.在诸如大型电子商务平台、大型SNS平台等互联网大数据应用场景中,OldSQL在应用中负责高价值密度结构化数据的存储和事务型处理,NoSQL在应用中负责存储和处理海量非结构化的数据和低价值密度结构化数据.OldSQL+NoSQL模式在互联网大数据应用中的互补作用体现在,OldSQL弥补了NoSQL在ACID特性和复杂关联运算方面的不足,NoSQL弥补了OldSQL在海量数据存储和非结构化数据处理方面的缺陷.
淘宝海量数据产品技术架构
NewSQL+NoSQL 在行业大数据应用中混合部署
行业大数据与互联网大数据的区别在于行业大数据的价值密度更高,并且对结构化数据的实时处理、复杂的多表关联分析、即席查询、数据强一致性等都比互联网大数据有更高的要求.行业大数据应用场景主要是分析类应用,如：电信、金融、政务、能源等行业的决策辅助、预测预警、统计分析、经营分析等.
在行业大数据应用中采用NewSQL+NoSQL混合模式,充分利用NewSQL在结构化数据分析处理方面的优势,以及NoSQL在非结构数据处理方面的优势,实现NewSQL与NoSQL的功能互补,解决行业大数据应用对高价值结构化数据的实时处理、复杂的多表关联分析、即席查询、数据强一致性等要求,以及对海量非结构化数据存储和精确查询的要求.在应用中,NewSQL承担高价值密度结构化数据的存储和分析处理工作,NoSQL承担存储和处理海量非结构化数据和不需要关联分析、Ad-hoc查询较少的低价值密度结构化数据的工作.
集中化BI系统数据存储架构
集中化BI系统按照数据类型和处理方式的不同,将结构化数据和非结构化数据分别存储在不同的系统中：非结构化数据在Hadoop平台上存储与处理;结构化、不需要关联分析、Ad-hoc查询较少的数据保存在NoSQL数据库或Hadoop平台;结构化、需要关联分析或经常ad-hoc查询的数据,保存在NewSQL MPP数据库中,短期高价值数据放在高性能平台,中长期放在低成本产品中.
结语
当前信息化应用的多样性、复杂性,以及三种数据库架构各自所具有的优势和局限性,造成任何一种架构的数据库都不能完全满足应用需求,所以呢不同架构数据库混合使用,从而弥补其他架构的不足成为必然选择.根据应用场景采用不同架构数据库进行组合搭配,充分发挥每种架构数据库的特点和优势,并且与其他架构数据库形成互补,完全涵盖应用需求,保证数据资源的最优化利用,将成为未来一段时期内信息化应用主要采用的解决方式.
早期需要延迟处理的业务场景,更多的是通过定时任务扫表,然后执行满足条件的记录,具有频率高、命中低、资源消耗大的缺点.随着消息中间件的普及,延迟消息可以很好的处理这种场景,本文主要介绍延迟消息的使用场景以及基于常见的消息中间件如何实现延迟队列,最后给出了一个在网易公开课使用延迟队列的实践.
①.、有效期：限时活动、拼团...
①.、RabbitMQ
①.）简介：基于AMQP协议,使用Erlang编写,实现了一个Broker框架
a、Broker：接收和分发消息的代理服务器
b、Virtual Host：虚拟主机之间相互隔离,可理解为一个虚拟主机对应一个消息服务
c、Exchange：交换机,消息发送到指定虚拟机的交换机上
d、Binding：交换机与队列绑定,并通过路由策略和routingKey将消息投递到一个或多个队列中
e、Queue：存放消息的队列,FIFO,可持久化
f、Channel：信道,消费者通过信道消费消息,一个TCP连接上可同时创建成百上千个信道,作为消息隔离
a、TTL：RabbitMQ支持对队列和消息各自设置存活时间,取二者中较小的值,即队列无消费者连接或消息在队列中一直未被消费的过期时间
b、DLE：过期的消息通过绑定的死信交换机,路由到指定的死信队列,消费者实际上消费的是死信队列上的消息
a、配置麻烦,额外增加一个死信交换机和一个死信队列的配置
b、脆弱性,配置错误或者生产者消费者连接的队列错误都有可能造成延迟失效
a、Broker：存放Topic并根据读取Producer的提交日志,将逻辑上的一个Topic分多个Queue存储,每个Queue上存储消息在提交日志上的位置
b、Name Server：无状态的节点,维护Topic与Broker的对应关系以及Broker的主从关系
a、时间轮(TimingWheel)：是一个存储定时任务的环形队列,底层采用数组实现,数组中的每个元素可以存放一个定时任务列表
b、定时任务列表(TimerTaskList)：是一个环形的双向链表,链表中的每一项表示的都是定时任务项
c、定时任务项(TimerTaskEntry)：封装了真正的定时任务TimerTask
d、层级时间轮：当任务的到期时间超过了当前时间轮所表示的时间范围时,就会尝试添加到上层时间轮中,类似于钟表就是一个三级时间轮
e、JDK DelayQueue：存储TimerTaskList,并根据其expiration来推进时间轮的时间,每推进一次除执行相应任务列表外,层级时间轮也会进行相应调整
a、延迟精度取决于时间格设置
b、延迟任务除由超时触发还可能被外部事件触发而执行
①.）简介：基于JMS协议,Java编写的Apache顶级开源项目,支持点对点和发布订阅两种模式.
a、点对点（point-to-point）：消息发送到指定的队列,每条消息只有一个消费者能够消费,基于拉模型
b、发布订阅（publish/subscribe）：消息发送到主题Topic上,每条消息会被订阅该Topic的所有消费者各自消费,基于推模型
a、Broker Filter：Broker中定义了一系列BrokerFilter的子类构成拦截器链,按顺序对消息进行相应处理
b、ScheduleBroker：当消息中指定了延迟相关属性,并且jobId为空时,会生成调度任务存储到JobStore中,此时消息不会进入到队列
c、JobStore：基于BTree存储,key为任务执行的时间戳,value为该时间戳下需要执行的任务列表
d、JobScheduler：取JobStore中最小的key执行（调度时间最早的）,执行时间=当前时间,将该任务列表依次投递到所属的队列,对于需要重复投递和投递失败的会再次存入JobStore中.
①.）简介：基于Key-Value的NoSQL数据库,由于其极高的性能常被当作缓存来使用,其数据结构支持：字符串、哈希、列表、集合、有序集合
a、实现复杂,本身不支持
b、完全基于内存,延迟时间长浪费内存资源
①.、公开课延迟队列技术选型
①.）业务场景：关闭超时未支付订单、限时优惠活动、拼团
结论： 最终选择ActiveMQ来作为延迟队列
①.）关闭微信未支付订单
①.）activemq.xml中支持调度任务
其中：
a、延迟处理
AMQ_SCHEDULED_DELAY：设置多长时间后,投递给消费者（毫秒）
b、重复投递
AMQ_SCHEDULED_PERIOD：重复投递时间间隔（毫秒）
AMQ_SCHEDULED_REPEAT：重复投递次数
c、指定调度计划
AMQ_SCHEDULED_CRON：corn正则表达式
①.）可靠性：针对实际投递时间可能翻倍的问题,结合ActiveMQ的重复投递,在消费者逻辑中做幂等处理来保证延迟时间的准确性
①.、无论是基于死信队列还是基于数据先存储后投递,本质上都是将延迟待发送的消息数据与正常订阅的队列分开存储,从而降低耦合度
第一段：消息中间件相关知识
①.、概述
消息队列已经逐渐成为企业IT系统内部通信的核心手段.它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一.当今市面上有很多主流的消息中间件,如老牌的ActiveMQ、RabbitMQ,炙手可热的Kafka,阿里巴巴自主开发RocketMQ等.
消息服务器,作为server提供消息核心服务
消息生产者,业务的发起方,负责生产消息传输给broker,
消息消费者,业务的处理方,负责从broker获取消息并进行业务逻辑处理
消息体,根据不同通信协议定义的固定格式进行编码的数据包,来封装业务数据,实现消息的传输
PTP点对点:使用queue作为通信载体
说明：
消息生产者生产消息发送到queue中,然后消息消费者从queue中取出并且消费消息.
消息被消费以后,queue中不再存储,所以消息消费者不可能消费到已经被消费的消息. Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费.
queue实现了负载均衡,将producer生产的消息发送到消息队列中,由多个消费者消费.但一个消息只能被一个消费者接受,当没有消费者可用时,这个消息会被保存直到有一个可用的消费者.
交互系统之间没有直接的调用关系,只是通过消息传输,故系统侵入性不强,耦合度低.
例如原来的一套逻辑,完成支付可能涉及先修改订单状态、计算会员积分、通知物流配送几个逻辑才能完成；通过MQ架构设计,就可将紧急重要（需要立刻响应）的业务放到该调用方法中,响应要求不高的使用消息队列,放到MQ队列中,供消费者处理.
通过消息作为整合,大数据的背景下,消息队列还与实时处理架构整合,为数据处理提供性能支持.
Java消息服务（Java Message Service,JMS）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信.
有些业务不想也不需要立即处理消息.消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它.想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们.
降低工程间的强依赖程度,针对异构系统进行适配.在项目启动之初来预测将来项目会碰到什么需求,是极其困难的.通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口,当应用发生变化时,可以独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束.
有些情况下,处理数据的过程会失败.除非数据被持久化,否则将造成丢失.消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险.许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕.
因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可.不需要改变代码、不需要调节参数.便于分布式扩容.
在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费.使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃.
系统的一部分组件失效时,不会影响到整个系统.消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理.
在大多使用场景下,数据处理的顺序都很重要.大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理.
在任何重要的系统中,都会有需要不同的处理时间的元素.消息队列通过一个缓冲层来帮助任务最高效率的执行,该缓冲有助于控制和优化数据流经过系统的速度.以调节系统响应时间.
分布式系统产生的海量数据流,如：业务日志、监控数据、用户行为等,针对这些数据流进行实时或批量采集汇总,然后进行大数据分析是当前互联网的必备技术,通过消息队列完成此类数据收集是最好的选择.
优点：可靠、通用
MQTT（Message Queuing Telemetry Transport,消息队列遥测传输）是IBM开发的一个即时通讯协议,有可能成为物联网的重要组成部分.该协议支持所有平台,几乎可以把所有联网物品和外部连接起来,被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议.
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统
优点：命令模式（非topic\queue模式）
XMPP（可扩展消息处理现场协议,Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议,多用于即时消息（IM）以及在线现场探测.适用于服务器之间的准即时操作.核心是基于XML流传输,这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息,即使其操作系统和浏览器不同.
优点：通用公开、兼容性强、可扩展、安全性高,但XML编码格式占用带宽大
有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范,而是基于TCP\IP自行封装了一套协议,通过网络socket接口进行传输,实现了MQ的功能.
具有以下特点：
官方提供了一些不同于kafka的对比差异：
Apache下的一个子项目,使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统,具有以下特性：
号称最快的消息队列系统,专门为高吞吐量/低延迟的场景开发,在金融界的应用中经常使用,偏重于实时数据通信场景.ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列,但是开发人员需要自己组合多种技术框架,开发成本高.所以呢ZeroMQ具有一个独特的非中间件的模式,更像一个socket library,你不需要安装和运行一个消息服务器或中间件,因为你的应用程序本身就是使用ZeroMQ API完成逻辑服务的角色.但是ZeroMQ仅提供非持久性的队列,如果down机,数据将会丢失.如：Twitter的Storm中使用ZeroMQ作为数据流的传输.
ZeroMQ套接字是与传输层无关的：ZeroMQ套接字对所有传输层协议定义了统一的API接口.默认支持 进程内(inproc) ,进程间(IPC) ,多播,TCP协议,在不同的协议之间切换只要简单的改变连接字符串的前缀.可以在任何时候以最小的代价从进程间的本地通信切换到分布式下的TCP通信.ZeroMQ在背后处理连接建立,断开和重连逻辑.
特性：
第二段：主要消息中间件的比较
以上就是土嘎嘎小编为大家整理的nosql数据库中间件相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！