分布式架构 分布式处理、分布式存储方面新的研究方向有哪些？
分布式处理、分布式存储方面新的研究方向有哪些？
近两年来分布式存储的研究趋势是效率、可扩展性和性能。效率的提高得益于云存储的普及。一般来说，云存储的投资比较大，所以成本控制非常重要。无论Amazon、qiniu还是其他厂商都希望存储成本尽可能低，所以虚拟化存储和擦除非常重要，还有一些研究人员在研究代码和复制；还有更多的人在研究可扩展性，这可以从fast/osdi/sosp等会议上看到。主要是规模扩张和移动平台扩张。在大数据时代，人人都有数据，对存储的需求也越来越大。原来的解决方案在这样的规模下难度更大，所以haystack有了这样的系统，移动平台更是多姿多彩，这从苹果IOS/Android存储文件系统的迭代就可以看出。性能是一个永恒的话题，对高性能的需求总是存在的。我曾经听说一家金融机构希望存储速度能和内存一样快。当然，这也是可能的，所以flash存储和相变存储已经成为热门，这也是各大会议的一大主题。另一个研究方向是功耗。我觉得这个比较小，有伪命题的色彩。分布式处理的主要方向是规模和效率。它支持更大的数据量和更快的计算速度。内存计算现在非常流行和有前途。
如何使用消息队列解决分布式事务？
有两种选择。
Scheme 1 Local message transaction table
生产者需要添加一个事务消息表。具体步骤如下：[1。生产者执行业务逻辑并将事务记录插入到消息表中。这两个操作在一个本地事务中
2。启动后台线程定期轮询消息表并将消息发送到消息队列
3。删除消息表中的消息，直到发送成功。
方案2需要消息队列支持，业务端提供回溯接口
1。生产端将准备好的消息发送到消息队列
2。在本地事务中，业务逻辑
3。根据执行结果确认或取消准备好的消息
4。消息队列将确保准备好的消息被确认或取消，并且消息队列将不断地向生产端请求执行结果，这要求生产端提供类似的回调函数。
在方案2中，消息队列取代了方案1中的消息表和后台线程轮询功能，但并非所有消息队列都支持此功能。支持Rocketmq。
方案1的开发工作量大，外部依赖性小
方案2的开发工作量小，但依赖于特定的消息队列。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
