背景

有个项目的需要是：用户通过给好友分享带有二维码的图片，好友扫码或在微信中识别二维码来领取分享的礼物。要实现这个需要，能想到的解决方案有两个：

本文转自：调整 Linux I/O 调度器优化系统性能

背景

查看RocketMQ文档的过程中，提到了通过修改IO调度算法来提高RocketMQ的性能。网上找了一些文章，感觉IBM这个文章不错。

前言

前言
Linux I/O 调度器是Linux内核中的一个组成部分，用户可以通过调整这个调度器来优化系统性能。本文首先介绍Linux I/O 调度器的结构，然后介绍如何根据不同的存储器来设置Linux I/O 调度器从而达到优化系统性能。

背景

为了保证在应用发布期间不间断用户的请求，我们需要实现后端服务的动态上下线。同时为了在OPS管理台能看到某个应用各个Server结点的健康状态，我们需要后端节点的健康检查功能。基于openresty，这些功能都可以实现。

文章转载自：TCP的三次握手和四次挥手

TCP连接建立过程——三次握手

• 第一次握手：客户端发送位码为 SYN = 1（SYN 标志位置位），随机产生初始序列号 Seq = J 的数据包到服务器。服务器由 SYN = 1（置位）知道，客户端要求建立联机。
• 第二次握手：服务器收到请求后要确认联机信息，向客户端发送确认号Ack = （客户端的Seq +1，J+1），SYN = 1，ACK = 1（SYN，ACK 标志位置位），随机产生的序列号 Seq = K 的数据包。
• 第三次握手：客户端收到后检查 Ack 是否正确，即第一次发送的 Seq +1（J+1），以及位码ACK是否为1。若正确，客户端会再发送 Ack = （服务器端的Seq+1，K+1），ACK = 1，以及序号Seq为服务器确认号J 的确认包。服务器收到后确认之前发送的 Seq（K+1） 值与 ACK= 1 （ACK置位）则连接建立成功。

背景

公司现有应用的部署方式是所有的请求通过一个外网域名进行访问，在openresty内部通过location匹配来分离请求到不同的upstream。这样的配置方式带来的最大问题至少有两个：

1. 配置膨胀。随着子应用接口的增加，location的配置会很复杂，不易阅读和新增配置。
2. 每次新增和删除接口都需要修改所有openresty配置。这会带来额外的运维负担，而且会影响部分接口的稳定性。

那有没有一种方式可以动态的新增和删除需要跳转的uri呢？ 这个就是下面我要提供的解决方案。

背景

进程内的对共享资源的互斥访问可以通过各个语言提供的Lock来实现。在分布式环境下对共享资源的访问就需要分布式锁的支持。分布式是锁的本质是都是找一个共同可以访问的资源，可以是分布式文件系统中的文件，某个固定结点的一块内存，等等。共享资源所在机器的进程来协调分布式的加锁和解锁请求。分布式的锁比进程内的锁需要考虑的问题还要多。下面就总结一下常用的分布式锁解决方案。

但是：能不用分布式锁就不要用了。性能，可扩展性，容错都很难处理。

CAP定理

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式存储系统来说，不可能同时满足以下三点:

• 一致性（Consistence） 每次读取都能获取最新的写入或一个ERROR
• 可用性（Availability）（每次请求都能获取到非ERROR的响应 – 但是不保证获取的数据为最新数据）
• 分区容错性（Network partitioning）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致(全部不更新能保证一致性)，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

runBlocking

声明

1
2
3
4
5
6
7
8
9
10

@Throws(InterruptedException::class)
public fun <T> runBlocking(context: CoroutineContext = EmptyCoroutineContext, block: suspend CoroutineScope.() -> T): T {
    val currentThread = Thread.currentThread()
    val eventLoop = if (context[ContinuationInterceptor] == null) BlockingEventLoop(currentThread) else null
    val newContext = newCoroutineContext(context + (eventLoop ?: EmptyCoroutineContext))
    val coroutine = BlockingCoroutine<T>(newContext, currentThread, privateEventLoop = eventLoop != null)
    coroutine.initParentJob(context[Job])
    block.startCoroutine(coroutine, coroutine)
    return coroutine.joinBlocking()
}

背景

本机安装了Jenkins后，每次开机都会自启动。浪费资源不说，主要是占用了8080这个人见人爱的端口。 通过下面的办法可以禁止它的自启动。

解决办法

1

launchctl unload -w /Library/LaunchDaemons/org.jenkins-ci.plist

通过这个例子指定，OSX上启动的的脚本都是放在目录/Library/LaunchDaemons下。该目录下的每个文件都是有特殊格式的。

如果想要制作自启动脚本，可以参考这个目录下的脚本。

本文转自：Gossip算法

Gossip算法因为Cassandra而名声大噪，Gossip看似简单，但要真正弄清楚其本质远没看起来那么容易。为了寻求Gossip的本质，下面的内容主要参考Gossip的原始论文：<>。

Gossip背景

Gossip算法如其名，灵感来自办公室八卦，只要一个人八卦一下，在有限的时间内所有的人都会知道该八卦的信息，这种方式也与病毒传播类似，因此Gossip有众多的别名“闲话算法”、“疫情传播算法”、“病毒感染算法”、“谣言传播算法”。

但Gossip并不是一个新东西，之前的泛洪查找、路由算法都归属于这个范畴，不同的是Gossip给这类算法提供了明确的语义、具体实施方法及收敛性证明。