本文基于《构建高性能网站》整理。之前对于各种IO模型的理解不是很清晰，发现这本书里整理得比较好，这里记录下相关要点。

阅读全文

作者:aCoder2013 首发博客地址:https://github.com/aCoder2013/blog/issues/3

前言

今天小伙伴遇到个小问题，线程池提交的任务如果没有catch异常，那么会抛到哪里去，之前倒是没研究过，本着实事求是的原则，看了一下代码。

阅读全文

原文链接 译者：flystarfly

介绍

使用消息代理（如RabbitMQ）的系统按定义分发。 由于发送的协议方法（消息）不能保证到达对方或被成功处理，所以发布者和消费者都需要一个交付和处理确认的机制。 RabbitMQ支持的一些消息协议提供了这样的功能。 本指南涵盖AMQP 0-9-1中的特性，但其他协议（STOMP，MQTT等）中的思路大致相同。

从消费者（consumers）投递rabbitmq代理(broker)的处理确认被认为是AMQP 0-9-1协议中的确认; rabbitmq代理(broker)对发布者(publishers)的确认被称作发布者确认(publisher confirms)
阅读全文

原文链接 译者：Emalia

Redis设计方案

Rdis设计方案是在新功能实际实施之前让社区了解新功能设计的一种方法。这样做是希望从用户基础获得良好的反馈，如果发现缺陷或者可能的改进，可能会导致设计的改变。
阅读全文

原文链接 译者：flystarfly

该文阅读自RabbitMQ官方网站，分享好文给大家

你在Rabbit有一个队列，然后一些消费者从这个队列中消费。如果你根本没有设置QoS（basic.qos），那么Rabbit会把所有的队列消息都按照网络和客户端允许的速度推送给客户端。消费者将会飞速增加它们的内存占用，因为它们将所有消息都缓存在自己的RAM中。如果您询问Rabbit，队列可能会显示为空，但会有大量在客户端中，正准备由客户端应用程序处理的消息未被确认。如果您添加新的消费者，则队列中不会有消息发送给新的消费者。即使有其他消费者可用于更快地处理这样的消息，它们也只是在现有的客户端缓存，并且可能在那里很长一段时间。这是相当次优的。

因此，默认的QoS预取设置为客户提供了无限的缓冲区，这可能导致不良的行为和性能。但是，怎样的QoS预取缓冲区大小才是您应该设置的？设置的目的是让消费者保持工作饱和状态，同时尽量减少客户端的缓冲区大小，以便更多的消息留在Rabbit的队列中，来可供新消费者使用，或在消费者空闲时发送给消费者。
阅读全文

11月天渐渐变亮，本月并发网开始组织翻译Spring Cloud大家庭，本文是第一篇《Spring Cloud Netflix官方文档》，欢迎有兴趣的同学参与。

阅读全文

原文地址  译者：克里斯托刘

经纪人拓扑结构(Broker Topology)

经纪人拓扑结构和调度员拓扑结构不同点在于，没有中央事件调度员，而是：消息执行流程沿着类似链条连接的各个事件处理模块，通过轻量级的消息经纪人（比如AcitveMQ, HornetQ）实现。这样的拓扑结构，在你只需要处理一个相对简单的事件处理流程，同时不想要中央事件调度员时候，特别适用。

在经纪人拓扑结构中，有两种主要的模块：经纪人模块和事件处理模块。经纪人模块可以是集中的，包含所有的用于事件处理流程的事件通道(event channel)，该事件通道可以做成消息队列或者消息主题(message topics)，或者两种的结合。

阅读全文

Criteria查询为HQL，JPQL和native SQL 查询提供了一种类型安全的替代方法。

Hibernate 提供了一个遗留下来比较旧的org.hibernate.CriteriaAPI，并且它不被推荐使用。没有功能开发将针对这些API。最终，特定于Hibernate的criteria 功能将被移植到JPA的扩展javax.persistence.criteria.CriteriaQuery。有关org.hibernate.CriteriaAPI的详细信息，请参阅传统Hibernate条件查询。

阅读全文

之前的教程中，我们创建了一个工作队列。在一个工作队列背后的假设是将每个任务都准确地交付给一个工作人员。在这个环节我们要做些完全不同的事情—我们将要把一个消息传递给多个消费者。这种模式被称为“发布/订阅”。
阅读全文

原文链接：A Java Fork/Join Framework(PDF) – Doug Lea

译序

Doug Lea 大神关于Java 7引入的他写的Fork/Join框架的论文。

响应式编程（Reactive Programming / RP）作为一种范式在整个业界正在逐步受到认可和落地，是对过往系统的业务需求理解梳理之后对系统技术设计/架构模式的提升总结。Java作为一个成熟平台，对于趋势一向有些稳健的接纳和跟进能力，有着令人惊叹的生命活力：

1. Java 7提供了ForkJoinPool，支持了Java 8提供的Stream。
2. 另外Java 8还提供了Lamda（有效地表达和使用RP需要FP的语言构件和理念）。
3. 有了前面的这些稳健但不失时机的准备，在Java 9中提供了面向RP的官方Flow API，实际上是直接把Reactive Streams的接口加在Java标准库中，即Reactive Streams规范转正了，Reactive Streams是RP的基础核心组件。Flow API标志着RP由集市式的自由探索阶段 向 教堂式的统一使用的转变。

通过上面这些说明，可以看到ForkJoinPool的基础重要性。

对了，另外提一下Java 9的Flow API的@author也是 Doug Lee 哦～

PS：基于Alex/萧欢 翻译、方腾飞 校对的译文稿：Java Fork Join 框架，补译『结论』之后3节，调整了格式和一些用词，整理成完整的译文。译文源码在GitHub的这个仓库中，可以提交Issue/Fork后提交代码来建议/指正。

0. 摘要

这篇论文描述了Fork/Join框架的设计、实现以及性能，这个框架通过（递归的）把问题划分为子任务，然后并行的执行这些子任务，等所有的子任务都结束的时候，再合并最终结果的这种方式来支持并行计算编程。总体的设计参考了为Cilk设计的work-stealing框架。就设计层面来说主要是围绕如何高效的去构建和管理任务队列以及工作线程来展开的。性能测试的数据显示良好的并行计算程序将会提升大部分应用，同时也暗示了一些潜在的可以提升的空间。

阅读全文

Topics

在上一个教程中，我们改进了我们的日志系统而不是使用只能进行广播的fanout交换类型，我们使用direct类型，能够选择性地接收日志。 虽然使用direct交换类型改进了我们的系统，但它仍然有限制 – 它不能基于多条件进行路由选择。 在我们的日志记录系统中，我们可能不仅要根据日志级别订阅日志，还可以基于日志源进行订阅。您可能会从syslog unix工具中了解过这个概念，该工具可以根据日志级别（info/warn/crit..）和设备（auth / cron / kern …）来路由日志。

这将给我们很大的灵活性 – 我们可能只想要监听来自“cron”的重要错误，但是想监听来自”kern“的所有日志。 要在我们的日志系统中实现这一点，我们需要了解一个更复杂的交换类型-Topic(主题)交换。

阅读全文

关于nginScript

nginScript是允许在 http 和 stream 中实现位置和变量处理程序的JavaScript语言的子集 。nginScript创建符合 ECMAScript 5.1 和一些 ECMAScript 6 扩展名。合规性仍在不断发展。

阅读全文

Routing

在上一节我们建立了一个简单的日志系统，已经能够传播日志信息给接收者了。

在这一节我们将给它增加一个特性-订阅部分消息。比如说，我们能够从控制台打印的所有日志信息中将至关重要的错误信息指向日志文件(保存在硬盘里)。

阅读全文