Archive for ‘ November, 2017

《译文:RabbitMQ 消费者确认和发布者确认》

原文链接 译者:flystarfly

介绍

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

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

《Redis官方文档》Redis设计方案

原文链接 译者:Emalia

Redis设计方案

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

浅谈AutoCloseable接口

一、前言

最近在翻看源码时候发现有些类实现了AutoCloseable接口,这个接口很生疏,所以搜了下资料,学习了下,下面做个总结。

Read more

《译文:RabbitMQ关于吞吐量,延迟和带宽的一些理论》

原文链接 译者:flystarfly

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

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

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

异步打印日志的一点事

一、前言

最近刚刚结束转岗以来的第一次双11压测,收获颇多,难言言表, 本文就先谈谈异步日志吧,在高并发高流量响应延迟要求比较小的系统中同步打日志已经满足不了需求了,同步打日志会阻塞调用打日志的线程,而打日志本身是需要写磁盘的,所以会造成rt增加。异步日志就是为了解决这个问题。

Read more

《Spring Cloud Netflix官方文档》翻译邀请

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

Read more

《软件架构模式》-第二章事件驱动架构(下)

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

经纪人拓扑结构(Broker Topology)

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

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

Read more

《Hibernate快速开始》Query /Criteria

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

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

Read more

《RabbitMQ官方文档》订阅与发布

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

Java Fork/Join框架

原文链接: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 StreamsRP的基础核心组件。Flow API标志着RP由集市式的自由探索阶段 向 教堂式的统一使用的转变。

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

对了,另外提一下Java 9Flow API@author也是 Doug Lee 哦~

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

0. 摘要

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

Read more

return top