superhx

介绍

“分而治之“是理清思路和解决问题的一个重要的方法。大到系统架构对功能模块的拆分，小到归并排序的实现，无一不在散发着分而治之的思想。在实现分而治之的算法的时候，我们通常使用递归的方法。递归相当于把大的任务拆成多个小的任务，然后大任务等待多个小的子任务执行完成后，合并子任务的结果。一般来说，父任务依赖与子任务的执行结果，子任务与子任务之间没有依赖关系。因此子任务之间可以并发执行来提升性能。于是ForkJoinPool提供了一个并发处理“分而治之”的框架，让我们能以类似于递归的编程方式获得并发执行的能力。

使用

分而治之代码典型的形式如下：

Result solve(Problem problem) {

superhx

本来是准备写读后感的，呃，介于水平和时间有限（偷懒），准备“暂时”先写一篇读书笔记来记录一下自己看《Chaos Engineering》觉得有意思和有感悟的地方吧。

在看《Chaos Engineering》这本书之前，就对Netflix的Chaos Monkey有所耳闻。如Chaos Monkey的名字一下，Chaos Monkey负责在生产环境中进行捣乱，随意的关掉应用实例，来测试系统的健壮性。其实刚看到Chaos Monkey的时候，不由的想起测试中的Monkey Test。虽然两者不是同一个东西，但是觉得两者的核心相似：随机性、探索未知。随机性好理解，因为两者都有Monkey（滑稽）。那探索未知是啥呢？测试人员虽然在使用Chaos Monkey和Monkey Test，有对自己的系统行为有一定的预期，但并不像单元测试、集成测试之类这些测试一样，确切知道会发生什么。因为Chaos Monkey和Monkey Test具有随机性，测试人员希望利用随机性来发现未知的问题。

呃，有点跑题。。。下面读书笔记zhai chao正式开始。

为什么需要Chaos Engineering？

首先来看看Chaos Engineering的定义。定义是一种浓缩和总结，全书都是围绕这个定义来展开，感觉这个定义贼准确。建议看完这本书的同学可以回过头来好好品味下这句话。

superhx

这里有个需求

将一个Map从Master同步到Slave

• 最终达到一致就行
• value变动的频率 >> key增加的频率 >> key减少的频率

简单粗暴

superhx

import java.util.Deque;
import java.util.LinkedList;
import java.util.List;
import java.util.concurrent.ConcurrentLinkedDeque;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ThreadLocalRandom;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;

superhx

import java.util.Queue;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.locks.LockSupport;

/**
 * @author Robin Han

superhx

import java.util.concurrent.TimeUnit;

/**
 * @author Robin Han
 */
public class SlidingWindow {
    private static final long RANGE = TimeUnit.SECONDS.toNanos(1);

    /* A slides cells record requests number in corresponding time range */
    private final int[] slides;

superhx

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;

/**
 * A mirror of token bucket
 *
 * @author Robin Han
 * @see TokenBucket
 */
public class LeakyBucket {

superhx

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;

/**
 * Lockless implementation of rate limiter.
 * <p>
 * The algorithm is based on token bucket rate limiting. If bucket don't have
 * enough token, the acquire will fail and return false. The token is added into
 * bucket at a fixed rate. When token size is bigger than capacity, the overflow
 * token will be dropped.

superhx

package xyz.robinhan.lockless;

import xyz.robinhan.lockless.strategy.WaitStrategy;

import java.util.Collection;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicReferenceArray;
import java.util.concurrent.locks.LockSupport;