分布式系统基础设施常用术语

原创转载请注明出处:http://agilestyle.iteye.com/blog/2371211

 

分布式缓存

主要作用用于在高并发环境下,减轻数据库的压力,提高系统的响应速度和并发吞吐。当大量的读写请求涌向数据库时,磁盘的处理速度与内存显然不在一个量级,因此,在数据库之前加一层缓存,能够显著提高系统的响应速度,并降低数据库的压力。

 

持久化存储

MySQL作为传统的关系型数据库,MySQL提供完整的ACID操作,支持丰富的数据类型、强大的关联查询、where语句等,能够非常容易地建立查询索引,执行复杂的内连接、外连接、求和、排序、分组等操作、并支持存储过程、函数等功能,产品成熟度高,功能强大。但是对于需要应对高并发访问并且存储海量数据的场景来说,出于对性能的考虑,不得不放弃很多传统关系型数据库原本强大的功能,牺牲了系统的易用性,并且使得系统的设计和管理变得更为复杂。

NoSQL与传统的关系型数据库最大的差别在于,它不使用SQL作为查询语言来查找数据,而采用key-value形式进行查找,提供了更高的查询效率及吞吐,并且能够更加方便地进行扩展,存储海量数据,在数千个节点上进行分区,自动进行数据的复制和备份。

 

消息系统

在分布式系统中,消息作为应用间通信的一种方式,得到了十分广泛的应用。消息可以被保存在队列中,直到被接受者取出,由于消息发送者不需要同步等待消息接受者的响应,消息的异步接收降低了系统集成的耦合度,提升了分布式系统协作的效率,使得系统能够更快地响应用户,提纲更高的吞吐。当系统处于峰值压力时,分布式消息队列还能够作为缓冲,削峰填谷,缓解集群的压力,避免整个系统被压垮。

 

垂直化搜索引擎

垂直化搜索引擎在分布式系统中是一个非常重要的角色,它既能满足用户对于全文检索、模糊匹配的需求,解决数据库like查询效率低效的问题,又能够解决分布式环境下,由于采用分库分表,或者使用NoSQL数据库,导致无法进行多表关联或者进行复杂查询的问题。

 

其它基础设施

  • 实时计算
  • 离线计算
  • 分布式文件系统
  • 日志收集系统
  • 监控系统
  • 数据仓库
  • CDN系统
  • 负载均衡系统
  • 消息推送系统
  • 自动化运维系统

Reference

大型分布式网站架构设计与实践 陈康贤 著

 

 

<think>嗯,用户这次的问题是关于搭建分布式系统常用方法技术,结合了之前提供的引用材料历史对话。用户似乎是个系统工程师或架构师,正在规划分布式架构,需要全面但实用的指导。 从引用材料看,用户特别关注几个核心痛点:运维复杂性(引用1)、分布式三态问题(引用2)、数据本地化计算(引用3)lease机制(引用4)。这些恰好对应分布式系统的关键挑战——运维管理、网络通信、计算调度一致性。 上次我详细讲解了Hadoop部署,这次需要更通用的方法论。用户可能希望了解不同场景下的架构选型,比如什么时候用微服务+容器化,什么时候用大数据生态。考虑到用户引用中提到了DynamoHBase,应该对NoSQL存储也有兴趣。 技术方案上需要分层展开:首先基础设施层(网络、节点管理),然后计算层(任务调度),最后是容错机制。特别要强调引用4的lease机制,这是解决分布式锁一致性的实用方案。数据本地化(引用3)也要重点说明,毕竟这是优化性能的关键。 用户可能还隐含了对比需求:比如传统Hadoop集群现代Kubernetes方案的差异。虽然问题没直接问,但在"常用方法"中可以自然融入,毕竟引用1提到微服务框架的运维问题。 最后要注意避免堆砌术语。比如解释"三态问题"(引用2)时,必须关联到实际设计策略——超时控制、幂等操作这些落地方案。Lease机制的时钟同步问题(引用4)也要用运维视角说明,比如NTP服务的必要性。</think>搭建分布式系统的核心在于解决**多节点协同、数据一致性与容错**问题,需结合架构设计、通信协议运维策略。以下是常用方法技术,结合引用内容分析: --- ### **一、基础架构设计** 1. **分层架构** - **计算层**:任务调度(如YARN、Kubernetes调度器) - **存储层**:分布式文件系统(HDFS)、对象存储(Ceph) - **通信层**:RPC框架(gRPC)、消息队列(Kafka) *引用[1]强调硬件网络将计算能力切割,需分层管理复杂性。* 2. **数据本地化计算** 将计算任务调度到存储节点本地,减少网络传输(如Spark的`locality`策略)[^3]。 ```python # Spark示例:优先选择数据所在节点执行任务 rdd = sc.textFile("hdfs://data/file.txt") rdd.map(lambda x: process(x)).collect() # 自动就近调度 ``` --- ### **二、核心问题解决技术** 1. **处理分布式三态问题**(成功/失败/超时)[^2] - **超时控制**:为所有RPC调用设置超时阈值(如gRPC的`deadline`)。 - **幂等性设计**:通过唯一ID确保重复请求不影响结果(如支付系统)。 - **补偿机制**:Saga模式,失败时触发反向操作回滚。 2. **数据一致性保障** - **Lease机制**: - 颁发者(如NameNode)授予客户端临时数据访问权,超时自动释放[^4]。 - 解决时钟同步问题:设置有效期 $T_{\text{lease}} = T_{\text{base}} + \Delta T$($\Delta T$为时钟误差容限)。 - **共识算法**: - Paxos/Raft:确保多个节点对数据状态达成一致(如Etcd)。 - Quorum机制:$W + R > N$($W$写票数,$R$读票数,$N$副本数)保证强一致性。 --- ### **三、容错与高可用** | **技术** | **应用场景** | **示例工具** | |-------------------|------------------------------|----------------------------| | 副本机制 | 数据持久化 | HDFS(3副本)、Cassandra | | 故障检测 | 节点健康监控 | ZooKeeper临时节点、心跳包 | | 自动故障转移 | 主节点宕机恢复 | Keepalived VIP漂移[^1] | | 状态恢复 | 任务中断后继续 | Flink Checkpoint机制 | *引用[4]指出Lease机制在颁发者宕机时,只需等待超时即可保证系统正确性。* --- ### **四、运维优化实践** 1. **统一运维管理** - 使用容器化(Docker)编排工具(Kubernetes)集中管理节点[^1]。 - 部署Prometheus+Grafana监控集群资源(CPU/网络延迟)。 2. **性能调优关键点** - **减少网络开销**:压缩传输数据(Snappy)、合并RPC请求。 - **负载均衡**:一致性哈希分配请求(如Nginx upstream)。 - **资源隔离**:Cgroups限制单任务资源,避免级联故障。 --- ### **五、典型架构方案选型** | **场景** | **推荐方案** | |------------------------|---------------------------------------| | 大数据批处理 | Hadoop+Spark(数据本地化计算[^3]) | | 微服务集群 | Kubernetes+Istio(服务网格治理) | | 高并发键值存储 | Redis Cluster(分片+主从复制) | | 强一致性数据库 | CockroachDB(Raft共识) | > **关键原则**: > - 优先考虑无状态服务,简化扩展。 > - 避免分布式事务(用最终一致性替代)。 > - 设计时默认网络不可靠(引用[2]的三态问题)。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值