标签: distributed-system

• 垂直分布:分布式处理相当于组织client-server application一个multitiered architecture .将逻辑上不同的组件放在不同的机器上.
• 横向分布:clients and servers在现代建筑中更常见的分布.A client或者server可以physically分成logically 等价的部分,但是每个部分都在它自己的完整数据集的共享上运行,从而平衡负载.

我试着了解vertical和之间有什么不同horizontal？" logically"和" physically" 的含义是什么？...但我不能!有谁知道.. ??

我在课堂上学过消息队列系统,但我还是不知道这些消息队列系统在实时场景中是如何工作的？有没有可以帮助我全面了解的教程？有人能解释我这些系统是如何工作的吗？

我目前正在尝试了解Lamport时间戳.考虑两个过程P1(产生事件a1,a2,...)和P2(产生事件b1,b2,......).设C(e)表示与事件e相关的Lamport时间戳.我为维基百科关于Lamport时间戳的文章中描述的每个事件创建了时间戳:

根据维基百科,以下关系适用于所有事件e1,e2:

如果e1发生在e2之前,那么C(e1)<C(e2).

我们来看看a1和b2.显然a1发生在b2之前,并且由于 C(a1)= 1且C(b2)= 3,因此关系成立:C(a1)<C(b2).

问题:对于b3和a3,这种关系不适用.显然,b3发生在a3之前.但是,C(b3)= 4,C(a3)= 3.因此,C(B3)<C(A3),并不能适用.

我误解了什么？非常感谢帮助!

在raft中,当节点重新启动时,它会尝试重做所有日志条目以赶上状态.但是如果节点在恢复阶段再次出现故障,节点会做两次操作.如果ops不是幂等的,那么这两次重做操作将违反状态机.

根据上面的描述,我的问题是,在实践中使用筏子的系统中使ops成为幂等的必要吗？

我正在为具有这些要求的项目寻找数据存储解决方案:

1. 应用程序在商店中动态创建容器/表.
2. 在一小段时间内(例如两周),表/容器并行获取大量插入物.最后一次阅读必须立即可用.
3. 插入的数据非常小,有4到6个数字列.
4. 需要小的查询/过滤支持,但没有联接或交叉查询.
5. 需要执行一些聚合函数,如"Count","Sum","Max","Min"和"Avg".

基本上,我需要一些像Windows Azure表存储但具有聚合功能的东西.

你会推荐什么？

我目前正在开发分布式系统,我们必须实施某种领导者选举.问题是我们希望避免所有计算机必须相互了解 - 但只有领导者.有没有一种快速的方式,我们可以使用例如广播来实现我们想要的？

或者,我们是否只需知道至少一个,以进行良好的领导者选举？

可以假设所有计算机都在同一个子网上.

谢谢你的帮助.

各种网站(如Hortonworks)建议不要为HDFS设置配置RAID主要是因为两个原因:

1. 速度限制为较慢的磁盘(JBOD表现更好).
2. 可靠性

建议在NameNode上使用RAID.

但是在每个DataNode存储磁盘上实现RAID呢？

我目前正在阅读有关分布式系统的信息，我面临着两个以类似方式描述的不同术语：复制和冗余。

谁能部分解释每个术语？

我正在浏览 Redis 和 Etcd 的基准文档页面。从基准数据来看，Etcd 与 Redis 一样高效。

https://redis.io/topics/benchmarks

https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md#benchmarks

示例 - 通过 100 个并行客户端设置 100k 个密钥，有效负载 - 256 字节

- on redis : 70K QPS 
- on Etcd : 50k QPS

但我不明白为什么 Etcd 和 Redis 一样高效，还是我的理解有问题？

Etcd 的原因应该是比 Redis 慢很多：

• Etcd 可能使用 SSD，但 Redis 仍然是内存数据库，因此应该具有更高的性能。
• Etcd 使用共识（Raft）提供强一致性，并且应该比 Redis 慢。因为Redis不保证一致性。

这是来自Kubernetes 文档：

一致且高度可用的键值存储用作 Kubernetes 所有集群数据的后备存储。

Kubernetes 内部是否有单独的机制来使 ETCD 更可用？或者 ETCD 是否使用 Raft 的修改版本来实现这种超能力？