分布式
文章平均质量分 92
Young丶
这个作者很懒,什么都没留下…
展开
-
一文理解分布式开发中的服务治理
业务在刚开始时都是单体应用,随着用户量和访问量的增加,在架构层面会发生变化,逐步由单体应用开发转为分布式应用开发,比如把单体应用中的每个模块都按照特定的方法拆分成一组独立的服务,服务与服务之间通过HTTP或者RPC方式调用。服务实例在启动时被加载到容器中,并将服务自身的相关信息,比如接口名称、接口版本、IP地址、端口等注册到注册中心,并使用心跳机制定期刷新当前服务在注册中心的状态,以确认服务状态正常,在服务终止时将其从注册表中删除。系统的可用性是分布式系统的重要指标,是系统容错能力的体现。...原创 2022-07-30 04:45:00 · 17149 阅读 · 0 评论 -
大家平时天天说的分布式系统到底是什么东西?
其实分析完了之后,大家应该就大概知道了,招聘JD上写这个分布式系统的设计和开发经验,其实他是一个很大的主题,里面包含很多的内容。你的系统一旦分布式了之后,通信、缓存、消息、事务、锁、配置、日志、监控、会话,等等各种原来单块系统场景下很容易解决的问题,都会变得很复杂,需要引入大量外部的技术。所以你有没有参与过类似这样的一个大的分布式系统?你有没有基于各种技术解决过分布式系统场景下的各种技术问题?这就是人家希望和要求的分布式系统设计和开发的经验。如果大家还没接触过,建议多去学习一下。原创 2023-09-15 10:45:00 · 1202 阅读 · 0 评论 -
Kafka的底层“真面目”
kafka是一个分布式消息队列。具有高性能、持久化、多副本备份、横向扩展能力。生产者往队列里写消息,消费者从队列里取消息进行业务逻辑。一般在架构设计中起到解耦、削峰、异步处理的作用。kafka对外使用topic的概念,生产者往topic里写消息,消费者从读消息。为了做到水平扩展,一个topic实际是由多个partition组成的,遇到瓶颈时,可以通过增加partition的数量来进行横向扩容。单个parition内是保证消息有序。每新写一条消息,kafka就是在对应的文件append写,所以性能非常高。原创 2023-08-21 07:45:00 · 10110 阅读 · 0 评论 -
万字总结Zookeeper客户端Curator操作Api
curator是Netflix公司开源的⼀套Zookeeper客户端框架,和ZKClient⼀样,Curator解决了很多 Zookeeper客户端⾮常底层的细节开发工作,包括连接重连,反复注册Watcher和 NodeExistsException异常等,是最流⾏的Zookeeper客户端之⼀。从编码风格上来讲,它提供了基于 Fluent的编程风格⽀持打开,我们可以看到,Curator包含了以下几个包:curator-framework:对zookeeper的底层api的一些封装;原创 2023-04-19 09:45:00 · 44746 阅读 · 0 评论 -
分布式一致性协议
两阶段提交协议,简称 2PC(2 Prepare Commit),是比较常用的解决分布式事务问题的方式,要么所 有参与进程都提交事务,要么都取消事务,即实现 ACID 中的原子性(A)的常用手段。分布式事务: 事务提供一种操作本地数据库的不可分割的一系列操作 “要么什么都不做,要么做全 套(All or Nothing)”的机制,而分布式事务就是为了操作不同数据库的不可分割的一系列操作 “要 么什么都不做,要么做全套(All or Nothing)”的机制。原创 2023-04-05 07:00:00 · 60749 阅读 · 0 评论 -
Gossip 协议
Gossip 协议也叫 Epidemic 协议 (流行病协议)。原本用于分布式数据库中节点同步数据使用, 后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。从 gossip 单词就可以看到,其中文意思是八卦、流言等意思,我们可以想象下绯闻的传播(或者流 行病的传播);gossip 协议的工作原理就类似于这个。gossip 协议利用一种随机的方式将信息传播到整 个网络中,并在一定时间内使得系统内的所有节点数据一致。原创 2023-04-04 08:42:28 · 42419 阅读 · 0 评论 -
面试官让我设计一个基于分布式锁的库存超卖方案,并发量很高的那种
你想,假如你现在iphone有1000个库存,那么你完全可以给拆成20个库存段,要是你愿意,可以在数据库的表里建20个库存字段,比如stock_01,stock_02,类似这样的,也可以在redis之类的地方放20个库存key。比如悲观锁,分布式锁,乐观锁,队列串行化,异步队列分散,Redis原子操作,等等,很多方案,我们对库存超卖有自己的一整套优化机制。释放锁之后,另外一个订单系统实例才能加锁,接着查库存,一下发现库存只有2台了,库存不足,无法购买,下单失败。接着,每秒1000个请求过来了,好!原创 2022-10-24 13:38:30 · 21268 阅读 · 0 评论 -
【无标题】
微服务架构使得可以通过明确定义的服务边界来隔离故障。但是像在每个分布式系统中一样,发生网络、硬件、应用级别的错误都是很常见的。由于服务依赖关系,任何组件可能暂时无法提供服务。为了尽量减少部分中断的影响,我们需要构建容错服务,来优雅地处理这些中断的响应结果。如果你不熟悉本文中的模式,那并不一定意味着你做错了。建立可靠的系统总是会带来额外的成本。原创 2022-10-14 15:33:24 · 24264 阅读 · 0 评论 -
单体架构服务转型至分布式的踩坑经历
书本定义:“软件的架构是一种抽象的结构,他由软件的各个组成部分和这些部分之间的依赖关系构成”。我的理解是,架构就是根据业务选择合适的技术、中间件,并且按照合适的设计模式对这些模块,进行组装来满足业务特性的需求。转载 2022-09-30 12:36:08 · 26261 阅读 · 0 评论 -
分布式理论分布式ID生成大全
日常开发中,我们需要对系统中的各种数据使用 ID 唯一表示,比如用户 ID 对应且仅对应一个人,商品 ID 对应且仅对应一件商品,订单 ID 对应且仅对应一个订单。我们现实生活中也有各种 ID,比如身份证 ID 对应且仅对应一个人、地址 ID 对应且仅对应简单来说,ID 就是数据的唯一标识。这篇文章中,我基本上已经把最常见的分布式 ID 生成方案都总结了一波。除了上面介绍的方式之外,像 ZooKeeper 这类中间件也可以帮助我们生成唯一 ID。没有银弹,一定要结合实际项目来选择最适合自己的方案。原创 2022-08-23 22:07:15 · 29354 阅读 · 0 评论 -
分布式理论之Raft 算法
举例如下:假如现在一共有 3 个将军 A,B 和 C,每个将军都有一个随机时间的倒计时器,倒计时一结束,这个将军就把自己当成大将军候选人,然后派信使传递选举投票的信息给将军 B 和 C,如果将军 B 和 C 还没有把自己当作候选人(自己的倒计时还没有结束),并且没有把选举票投给其他人,它们就会把票投给将军 A,信使回到将军 A 时,将军 A 知道自己收到了足够的票数,成为大将军。每个服务器的状态机按照日志顺序处理已提交的命令,并将输出返回给客户端,因此,这些服务器形成了一个单一的、高度可靠的状态机。原创 2022-08-20 12:57:22 · 29738 阅读 · 0 评论 -
分布式理论之Paxos 算法详解
Paxos 算法是 Leslie Lamport(莱斯利·兰伯特open in new window)在1990年提出了一种分布式系统共识算法。这也是第一个被证明完备的共识算法(前提是不存在拜占庭将军问题,也就是没有恶意节点)。为了介绍 Paxos 算法,兰伯特专门写了一篇幽默风趣的论文。在这篇论文中,他虚拟了一个叫做 Paxos 的希腊城邦来更形象化地介绍 Paxos 算法。不过,审稿人并不认可这篇论文的幽默。原创 2022-08-20 10:59:37 · 30505 阅读 · 0 评论 -
分布式理论之 CAP & BASE 详解
CAP也就是Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)这三个单词首字母组合。CAP 理论的提出者布鲁尔在提出 CAP 猜想的时候,并没有详细定义、、三个单词的明确定义。因此,对于 CAP 的民间解读有很多,一般比较被大家推荐的是下面 👇 这种版本的解读。一致性(Consistency): 所有节点访问同一份最新的数据副本可用性(Availability)原创 2022-08-20 10:44:50 · 29761 阅读 · 0 评论