hyflow-go

Go 开发的高一致性分布存储
授权协议 GPL
开发语言 Google Go
所属分类 服务器软件、 分布式应用/网格
软件类型 开源软件
地区 不详
投 递 者 白信鸿
操作系统 跨平台
开源组织
适用人群 未知
 软件概览

hyflow-go是一款可进行地理复制、主内存main-memory的高一致性数据存储,其最大特点是将低延时和高事务完美统一。

其模板化的架构:
1. 事务层:基于commit-time事务认证,灵活支持传统数据库的MVCC( Multi-Version Concurrency Control )和 single-versioning。能用来提供串行化serializability 或EUS(Extended Update Serializability ),这些依赖于底层的顺序Order层。

2.顺序层Ordering Layer:一致性的协议是可插拔的,可选择偏序(partial order)协议,如 Alvin POB, M2Paxos 或 E‑Paxos;或者完整顺序协议如:Multi‑Paxos 和 Raft。

3.通讯层:最底层是用来进行集群通信,背后使用 zeromq, nanomsg 或 mangos,乐观批处理用于在保持低延迟的同时增加吞吐量。

细节技术:
事务的偏序(Partial Ordering of Transactions)

通过跟踪事务之间的冲突,能够避免顺序(串行化serializing) 非冲突事务,这就增强了并发性,允许事务更快地提交。一些非串行化non-serializable执行也是允许的。

多主Multi-Master

在Alvin POB 和 E-Paxos协议中,每个节点负责协调本地的事务组织。对于客户端来说只需要一个来回即可,降低了延迟。这样,事务不必依赖一个全局的顺序领头者。

Fast Path

在不存在并发竞争情况下, Alvin POB 和 E-Paxos 能通过使用快速仲裁通过一个来回请求响应降低延迟,快速仲裁大于经典仲裁。

Go语言在编写分布式系统的好处是:
快速原型:hyflow-go是一款研究软件,Go语言特别适合,它是高阶语言,有很低开销,编译速度快,自动内存管理和内置并发,所有这些让研究人员和开发人员能够更专注于研究他们试图解决的问题。这样就减少通过软件工程的依赖约束。

高性能:Gi是快速的,能够编译到原生代码,提供的高级别的内存布局和分配的控制,内置的分析器允许开发人员检测和优化代码。

易于部署:编译自足的静态二进制文件,没有虚拟机或其他依赖设置。

 相关资料
  • 「工欲善其事,必先利其器!」 然后,比「 XXX 是最好的语言」更难的问题来了! XXX 是最好的操作系统、编辑器、IDE(集成编辑环境)。。。连 Wikipedia 上都创建了专门的页面。。。 :-X Operating system advocacy Editor war 「文无第一,武无第二」,个人无意更无力解决 「程序员鄙视链」 难题, 能输出才是王道,我们更应该 「放弃编程技术好坏之争,

  • 分布式共识算法 (Consensus Algorithm) 如何理解分布式共识? 多个参与者 针对 某一件事 达成完全 一致 :一件事,一个结论 已达成一致的结论,不可推翻 有哪些分布式共识算法? Paxos:被认为是分布式共识算法的根本,其他都是其变种,但是 paxos 论文中只给出了单个提案的过程,并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述,实现 paxos 具有很

  • 主要内容:一、写在前面,二、active-standby高可用架构,三、Master-Slave架构的分布式计算系统,四、弹性计算资源调度机制,五、分布式系统高容错机制,六、阶段性总结一、写在前面 商家数据平台第一个阶段的架构演进过程中,通过离线与实时计算链路的拆分,离线计算的增量计算优化,实时计算的滑动时间窗口计算引擎,分库分表 + 读写分离,等各种技术手段,支撑住了百亿量级的数据量的存储与计算。 我们先来回看一下当时的那个架构图,然后继续聊聊这套架构在面对高并发、高可用、高性能等各种技术挑战

  • IDE vs Text Editor Eclipse PDT (Eclipse PHP Development Tools) PHPStorm Sublime Text Vim Emacs … 扩展阅读 PHPStorm 短视频系列教程:Be Awesome in PHPStorm - 英文,推荐 JetBrains 官方短视频系列教程:PhpStorm Video Tutorial - 英文,不

  • 主要内容:背景引入,库存超卖现象是怎么产生的?,用分布式锁如何解决库存超卖问题?,有没有其他方案可以解决库存超卖问题?,分布式锁的方案在高并发场景下,如何对分布式锁进行高并发优化?,分布式锁并发优化方案有没有什么不足?,该优化方案的后续改进今天给大家聊一个有意思的话题:每秒上千订单场景下,如何对分布式锁的并发能力进行优化? 背景引入 首先,我们一起来看看这个问题的背景? 前段时间有个朋友在外面面试,然后有一天找我聊说:有一个国内不错的电商公司,面试官给他出了一个场景题: 假如下单时,用分布式锁来

  • 问题内容: 各位开发人员,大家好。 我正忙于android从应用程序上传图像。 我也可以使用它(代码将在下面)。 但是,当我发送大图像(10兆像素)时,我的应用程序因内存不足异常而崩溃。 一个解决方案是使用压缩,但是如果我要发送完整尺寸的图像怎么办? 我想也许有些东西在溪流中,但我不喜欢溪流。也许urlconnection可能有帮助,但我真的不知道。 我给文件名命名为File [0到9999] .