今天给大家分享一个大数据里面很火的技术——Kafka，Kafka是一个分布式的消息系统，其高性能在圈内很出名。本人阅读过多个大数据生态的开源技术的源码，个人感觉Kafka的源码质量是比较高的一个，如果有同学感兴趣的话，可以拿来阅读一下。网上也有不少的文章分析Kafka的性能为什么那么好，但是我感觉很多文章都没说到点上，所以今天借着这个机会跟大家交流一下kafka的性能为什么那么好？优秀设计之基于N
2PC必须注意的问题咱们上文介绍了分布式事务的常见方案、类型划分、2PC的起源和流程。但是不幸的是2PC还是存在几个问题：1、全流程的同步阻塞：不管是第一阶段还是第二阶段，所有参与节点都是事务阻塞型。当参与者占有公共资源时，其他第三方访问公共资源可能不得不处于阻塞状态。2、TM单点故障：由于全流程依赖TM的协调，一旦TM发生故障。参与者会一直阻塞下去。尤其在第二阶段，TM发生故障，那么所有的参与者
Kafka是一个高吞吐量的分布式的发布订阅消息系统，在全世界都很流行，在大数据项目里面使用尤其频繁。笔者看过多个大数据开源产品的源码，感觉Kafka的源码是其中质量比较上乘的一个，这得益于作者高超的编码水平和高超的架构设计能力。Kafka的核心源码分为两部分：客户端源码和服务端源码，客户端又分为生产者和消费者，而个人认为Kafka的源码里面生产者的源码技术含量最高，所以今天给大家剖析Kafka的生
首先准备一个hadoop源码包，我选择的hadoop版本是：hadoop-2.7.7-src.tar.gz，在hadoop-2.7.7的源码包的根目录下有一个文档叫做BUILDING.txt，这其中说明了编译hadoop所需要的一些编译环境相关的东西。不同的hadoop版本的要求都不一样，对应的版本参照BUILDING.txt安装对应软件（必须联网）安装openssl-develyum-yinst
《Hive底层执行引擎的深度剖析》的公开课，助力懵懂小伙伴进阶真正的Hive顶尖高手。
最近公司急招架构师，形形色色的人面了很多，但真正懂得设计思维的真的是少之又少。印象最深刻的一个同学，面对我提问的这个问题的时候，回答真的是让我佩服的五体投地！问：“你们公司为什么会选择用RocketMQ，而不是ActiveMQ、RabbitMQ？”当时他给我的答案是：当时领导决定的！一个用消息队列好几年的人，却不知道它的工作原理，也没有评估引入这些不同的组件会给项目带来何种风险的意识，不知道这样的
分布式系统中，大部分系统调用都会涉及到负载均衡，例如：客户端发往服务端的请求首先到达反向代理，然后反向代理再通过负载均衡算法将请求转发到业务系统；或者后端业务系统各模块间的调用前，也需要通过负载均衡算法选择到一个目标节点
分布式系统为了保证其可靠性，一般都会多节点提供服务，各别节点的故障不会影响系统的可用性。对于分布式的存储系统来说，在保证可用性的同时，数据的可靠性（不丢失）也是其要解决的核心问题。目前通用的方案是使用多副本存储。这就会引入一个新的问题，分布式存储系统的又一核心问题——多个副本间的数据一致性保障。所以就有了各种数据一致性协议。例如：Zookeeper的Zab、Etcd使用的Raft和无比复杂的Pax
分布式一致性分布式场景下，多个服务同时对服务一个流程，比如电商下单场景，需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败，或者网络不通引起的请求丢失，那么整个系统可能出现数据不一致的原因。上述场景就是分布式一致性问题，追根到底，分布式一致性的根本原因在于数据的分布式操作，引起的本地事务无法保障数据的原子性引起。分布式一致性问题的解决思路有
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
