熟悉 Java 并发编程的都知道，JMM(Java 内存模型) 中的 happen-before(简称 hb)规则，该规则定义了 Java 多线程操作的有序性和可见性，防止了编译器重排序对程序结果的影响。按照官方的说法：
当一个变量被多个线程读取并且至少被一个线程写入时，如果读操作和写操作没有 HB 关系，则会产生数据竞争问题。 要想保证操作 B 的线程看到操作 A 的结果（无论 A 和 B 是否在一个线程），那么在 A 和 B 之间必须满足 HB 原则，如果没有，将有可能导致重排序。 当缺少 HB 关系时，就可能出现重排序问题。
原文链接 邀请者：小村长
本篇是 Python官方文档的的翻译邀请函。只从AlphaGo成功挑战世界围棋冠军之后，在软件工程界掀起了一股人工智能热。而Python凭借着大量丰富的机器学习库迎来了人生的第二春，从此Python与机器学习人工智能接下了不解之缘。并发编程网在此也借助广大的技术爱好者们，希望给大家带来更高质量的Python技术文档。本次翻译希望大家积极参加为技术推广做一份小小的贡献，在此村长向所有参入开源热衷于技术推广的有志之士表示深深的谢意，在端午节来临之际，提前祝愿大家磕家欢乐，幸福健康一万年。
通过评论领取想要翻译的文章，每次领取一章或一节（根据内容长短），翻译完后再领取其他章节。领取完成之后，译文最好在一个星期内翻译完成，如果不能完成翻译，也欢迎你邀请其他同学和你一起完成翻译。
翻译完成之后请登录到并发网提交成待审核状态，会有专门的编辑校对后进行发布。如果多篇文章翻译被评为A级会升级您为译者，并加入译者沟通微信群。如果在本站翻译超过十篇文章，将有礼品赠送，比如签名版的《Java并发编程的艺术》或者荣誉译者奖杯等。如果你喜欢使用markdown编写文章，可以将markdown生成后的HTML复制到网站上进行提交，mac下推荐使用MacDown软件。
将成员变更纳入到算法中是Raft易于应用到实践中的关键，相对于Paxos，它给出了明确的变更过程（实践的基础，任何现实的系统中都会遇到因为硬件故障等原因引起的节点变更的操作）。
显然，我们可以通过shutdown集群，然后变更配置后重启集群的方式达到成员变更的目的。但是这种操作会损失系统的可用性，同时会带来操作失误引起的风险。支持自动化配置，即配置可以在集群运行期间进行动态的变更（不影响可用性）显示是一个非常重要的特性。
在同一个jvm进程中时，可以使用JUC提供的一些锁来解决多个线程竞争同一个共享资源时候的线程安全问题，但是当多个不同机器上的不同jvm进程共同竞争同一个共享资源时候，juc包的锁就无能无力了，这时候就需要分布式锁了。常见的有使用zk的最小版本，redis的set函数，数据库锁来实现，本节我们谈谈使用数据库悲观锁机制来实现一个分布式锁。 阅读全文
之前的两篇文章更多的是在描述Raft算法的正常流程，没有过多的去讨论异常场景。
而实际在分布式系统中，我们更多的都是在应对网络不可用、机器故障等异常场景，所以本篇来讨论一下Raft协议的安全性，即在异常场景下是否会导致数据丢失、数据不一致等情况。
Raft采用心跳机制来触发Leader选举。Leader周期性的发送心跳（如果有正常的RPC的请求情况下可以不发心跳）包保持自己Leader的角色（避免集群中其他节点认为没有Leader而开始选举）。
Follower在收到Leader或者Candidate的RPC请求的情况下一直保持Follower状态。而当一段时间内（election timeout）没有收到请求则认为没有Leader节点而出发选举流程。
在同一个jvm进程中时，可以使用JUC提供的一些锁来解决多个线程竞争同一个共享资源时候的线程安全问题，但是当多个不同机器上的不同jvm进程共同竞争同一个共享资源时候，juc包的锁就无能无力了，这时候就需要分布式锁了。常见的有使用zk的最小版本，redis的set函数，数据库锁来实现，本节我们谈谈使用zookeeper的序列节点机制来实现一个分布式锁。 阅读全文
分布式系统除了提升整个体统的性能外还有一个重要特征就是提高系统的可靠性。
提供可靠性可以理解为系统中一台或多台的机器故障不会使系统不可用（或者丢失数据）。
保证系统可靠性的关键就是多副本（即数据需要有备份），一旦有多副本，那么久面临多副本之间的一致性问题。
一致性算法正是用于解决分布式环境下多副本之间数据一致性的问题的。
在同一个jvm进程中时，可以使用JUC提供的一些锁来解决多个线程竞争同一个共享资源时候的线程安全问题，但是当多个不同机器上的不同jvm进程共同竞争同一个共享资源时候，juc包的锁就无能无力了，这时候就需要分布式锁了。常见的有使用zk的最小版本，redis的set函数，数据库锁来实现，本节我们谈谈Redis单实例情况下使用set函数来实现分布式锁。 阅读全文
作者：刘文敏
本文所说的包不是LV，也不是Chanel，而是Java语言中的包package，是Java程序员从写“Hello World”开始就接触的概念，Java引入包机制是为了更好的组织类，防止命名冲突，进行访问控制，提供搜索和定位类。
程序员对包的使用可以说是烂熟于心，但是笔者近日在自动构建后代码合规检查过程中发现了一个有趣的现象，某个Ant项目在自动构建时顺利通过，而代码合规检查的报告中则有许多类报声明的包”com.test“与期望的包”com.Test“不匹配这类错误，查看报错的源文件及文件目录，笔者发现源文件中写的是类似package com.test，而文件目录则为com\Test，笔者对Ant能编译通过深感好奇与困惑，立马写一个测试程序进行试验。
原文链接 译者：克里斯托刘
《软件架构模式》-第四章 微服务框架模式（下）
避免依赖和编排
设计微服务架构的一个主要难度是为服务组件选择正确的粗细粒度。如果服务组件设计的太粗糙，就彰显不了这种架构模式带来的好处（如部署、可扩展性、可测试性和松耦合）。但是，服务组件设计的过于细化，对服务组件编排要求更高，将你的微服务系统演变成面向服务的重量级体系结构，通常会带来缺点如复杂性、误导性、高开销，这些都是能在基于SOA的应用程序中找到的。
David John Wheeler有一句名言“计算机科学中的任何问题都可以通过加上一层间接层来解决”，一层不够就再加一层。后半句是我加的 (*￣︶￣) ，虽然有点玩笑的意思，但是也的确能说明一些问题。计算机科学的确是靠着一层又一层的抽象与封装解决了巨量的问题。
在讲解Netty客户端程序时候我们提到指定NioSocketChannel用于创建客户端NIO套接字通道的实例，下面我们来看NioSocketChannel是如何创建一个Java NIO里面的SocketChannel的。
Kafka在0.10版本推出了Stream API，提供了对存储在Kafka内的数据进行流式处理和分析的能力。
本文将从流式计算出发，之后介绍Kafka Streams的特点，最后探究Kafka Streams的架构。
(9 votes, average: 3.56 out of 5)
Loading...