【第22期】观点:IT 行业加班,到底有没有价值?

Eventual Consistency & Modules in Redis

原创 2016年08月31日 22:15:19

 本文将主要简单了解Redis的Eventual Consistency与令人期待的Redis Modules新功能。

1. Eventual Consistency

对于一致性,可以分为从客户端和服务端两个不同的视角。从客户端来看,一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看,则 是更新如何复制分布到整个系统,以保证数据最终一致。
我们知道多数分布式系统只能做到Eventual Consistency,即经过一定时间后,所有的node最终达成数据一致(good things will eventually happen)。
下图是典型的多数据中心,最终一致性的实现架构。



有机会也可以介绍我们目前的一个金融系统的架构,全球多数据中心海量数据如何通过EMS, Replication等机制做到最终一致性。

回到Redis, 单机版的Redis保证了CP(Consistency & Partition-Tolerancy), Consistency为强一致性,Redis Cluster在2015年3.0版本中则引入分布式,随之模型则变为支持AP(Avaiability & Partition-Tolerancy),Consistency为最终一致性(Eventual Consistency),无法保证强一致性。

然而,最终一致性并无法解决安全/正确性问题,如最终一致的数据如何选出,万一有数据在“最终一致前”就返回则无法保证其正确性。

Redis Cluster的读写请求只支持Master节点,当一请求在对应的Master写成功后,立刻返回给客户端成功信息,同时Master则通过异步的方式将新的数据同步到对应的Slave, 可以看出在保证了高效的速度下,还是存在数据会丢失的情形:

  • Master在返回客户成功后宕机(从而重新选主,但丢失了刚刚写的记录)
  • 当网络发生脑裂(split-brain)或者partitioned cluster集群分裂为多数派与少数派,如果数据继续写入少数派的Master,则当Cluster感知,并停止少数派Master,或者重新选主时,则面临丢失刚才已写入少数派的数据

对于Redis目前的Eventual Consistency, 如果业务严苛或者需要强一致性,目前只能建议或者选择其它关系型数据库(之后再同步到Redis),或者自行通过WAIT命令,但也只能解决上述问题一,而针对Split-brain目前比较棘手。

2. Redis Modules

可加载模块是Redis的新鲜尝试,可以称之为下一个里程碑,目前应该尚未发布,喜欢尝鲜的同学可以在unstable中体验,Antirez称希望可以在4.0稳定版本中见到。

多年来,Redis作为开源系统,其扩展性对于程序员来讲只能通过七种武器之一的lua脚本,要么直接修改redis源码(很多公司也确实是这么做的,因为一个系统不可能满足所有客户的需求,客户在面临取舍中只好自给自足)。然而lua脚本扩展性有限,并且无法直接访问redis底层的存储数据以及调用底层API;而修改源码则面临自己需要维护版本的问题,即需要不断与redis的分支进行合并。

Redis这个新的可加载模块则希望向Apple AppStore或者Android Marketplace一样,打造一个全新的Redis生态系统,使得开发人员可以编写自己扩展, 可拔插的模块,同时可以访问Redis底层核心API,Antirez对于这个新的尝试自己评价说“It was a matter of time but it eventually happend",Redis的潘多拉魔盒已经打开。

我们来看一个简单事例吧:

Redis扩展模块的形式是很固定的,需要编写且只编写两个部分:注册命令的函数和具体实现命令的函数。

简单来说,外部模块可以引用redismodule.h中的所有API, 包括访问Redis的字典空间,内存访问,调用Redis命令,向客户端返回数据等功能。外部模块最终以动态库的形式被server加载使用,并可以做到启动或者动态加载。可以看出,由于模块仅仅依赖redismodule.h暴露的接口,而并不依赖于实现本身,因此可以兼容redis的版本升级。

Redis模块的初始版本已经支持各种通用可拔插模块,包括全文搜索模块,图像处理,认证模块,安全模块等等。



自动内存管理

我们知道使用C语言开发,或者扩展Redis,编写Redis模块API都需要自己手动管理内存,进行对象内存分配,释放。追求性能之余也增加了复杂性。而当Redis引入模块,支持模块运行于容器环境时,同时也具备了支持自动内存管理的沙箱。果然,Redis开始提供模块中自动内存管理功能,当然以性能著称的Redis在提供此功能时也需要有部分性能损耗,Antirez自己说most of time, a very low cost。


当然,好比你也可以在手自一体的车上,使用手动档,必要时人工管理释放内存,然而,本质上,手自一体的已然是自动变速箱,只是提供了手工变速的体验而已。



总结

希望本文对Redis开发人员有所帮助,碰到一些实现细节,建议还是要深入其源代码一探究竟。另外也参考了Antirez的官网博客,有兴趣的朋友也可以关注。



技术朋友也可以关注作者的公众号:技术极客TechBooster
 








版权声明:本文为博主原创文章,未经博主允许不得转载。 举报

相关文章推荐

Docker

很早就想写一篇关于Docker的文章了,但却久久未动笔,直到最近社区再无Docker了,在2017年4月17日的DockerCon17上,开源项目Docker变更为Moby,好吗,膜拜单车了,开始动笔...

大型互联网技术架构4-分布式存储-II Google

大型互联网技术架构4-分布式存储-II; 分布式文件系统 - Google GFS; 分布式键值系统- Alibaba Tair;分布式表格系统- Google BigTable /Megastore...

程序员升职加薪指南!还缺一个“证”!

CSDN出品,立即查看!

Spring分布式动态数据源+事务

本篇是一个真实案例,来源于与一位技术达人一起共同探讨,解决一个分布式事务中,如何动态管理,切换数据库,适用于大型互联网,及分库管理系统。网上虽有很多相似问题,但却无可靠,有效之解决方案。

Spring Boot

Spring Boot是由Pivotal公司(Spring目前隶属于Pivotal)于2014发布的一个框架,如上图官网所示其设计目的是简化新Spring应用搭建及开发过程,尤其大幅减少Spring被...

Machine Learning 2 - 非线性回归算法分析

2017-08-02@erixhao  技术极客TechBooster AI 机器学习第二篇 - 非线形回归分析。我们上文深入本质了解了机器学习基础线性回归算法后,本文继续研究非...

大型互联网技术架构3-分布式存储-I

我们继续互联网技术架构-分布式存储。 总目录: 分布式存储概述 分布式存储特性 - 哈希分布/一致性哈希分布 分布式存储协议 - 两阶段与Paxos

spring atomikos 实现多数据源 分布式事务

spring 2.5以后,spring 删除了JotmFactoryBean ,spring不再提供对jotm提供支持 spring atomikos 集成 atomikos需要的jar a...

Atomikos分布式事务中切换数据源

分布式XA事务管理,多数据源动态切换, atomikos

深入了解Redis

本文将主要从Redis适用范围,与Memcached, Java容器对比,核心功能(Pipelining,Pub/Sub,LRU,Transactions, Persistence, Replicat...

FinTech-Blockchain区块链

最近有同事研究Blockchain, 作为曾今在投行打拼过的人事,好吧,投行IT,更加适合来研究介绍新一代的黑科技FinTech-Blockchain,区块链, 另外其实区块链与最近研究的分布式存...
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)