Java中使用akka手记三 Cluster详例

一个例子

  • 同样是typesafe的经典例子。
  • 例子提供的服务是传输文本。当文本发给frontend节点,它会委派backend节点,backend执行转化任务,把结果返回给原来的客户端。
  • 新的backend节点和frontend节点,都可以动态地在cluster上增减。

Java中使用akka手记二 Cluster

基础知识

  • 2.3.2的cluster还有些想实现的东西没有实现,包括:actor分区(负载均衡) actor handoff(临时故障时的actor处理) actor重新平衡(增减节点时有用) actor状态复制机制(类似做M/S作用)

  • 2.3.2的cluster已经有的能力有:节点-集群-leader节点; membership; gossip协议同步状态; VECTOR CLOCKS保障顺序; 失败检测-节点不可达算法; seed节点-新节点加入时可以向这些节点发消息,但也是可以向任意成员发的; membership生命周期有joining up leaving exiting removed unreachable几种状态。

Java中使用akka手记一

什么是actor?

  • Actor模型在并发编程中是比较常见的一种模型。很多开发语言都提供了原生的Actor模型。例如erlang,scala等。
  • 它由Carl Hewitt于上世纪70年代早期提出,目的是为了解决分布式编程中一系列的编程问题。
  • Actor模型的本质已经被强调了无数遍:万物皆Actor。Actor之间只有发送消息这一种通信方式。
  • 一个Actor如何处理多个Actor的请求呢?它先建立一个消息队列,每次收到消息后,就放入队列,而它每次也从队列中取出消息体来处理。通常我们都使得这个过程是循环的。让Actor可以时刻处理发送来的消息。

什么是akka?

Akka是一个用Scala编写的库,用于简化编写容错的、高可伸缩性的Java和Scala的Actor模型应用。

Phonegap试用手记

phoneGap是什么?

就是个壳子,方便原来做web开发的同学快速切入移动端开发。 本手记最终将生成“五四陈科学院”android版本和ios版本。

安装

基础环境是rmbp,有java环境,有xcode环境。

Io不再神秘

随着所有的在高可用服务器设计上的炒作,以及nodejs背后的风行,我想关注一些IO的设计模式,却一起没有足够的时间。现在正在完成的一些研究,我想最好记下这些资料以备查。让我们跳上IO bus兜风去。

各种各样的I/O

根据操作的阻塞或非阻塞类型,以及IO的准备就绪、完成事件通知的同步和异步类型,一共有四种不同方式的IO。

中大型移动互联网公司技术架构选择

总体思考

总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:

  • 可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问)
  • 天然可扩展(业务层无状态,尽可能全部放到最后)
  • 自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可)
  • 框架化(公共层面的东西尽可能框架化,一层类似日志、counter、trace,应该不需要开发再写一行代码即默认打开)
  • 量化(所有的调用都应该有percentile与rps,透明反馈服务质量,跟踪系统更是可以模拟用户进行系统内部)
  • 同构化(因为搞两套的成本巨大,整体应该越来越趋同于同一种语言)
  • 硬件虚拟化(整个平台应该对进程透明下面的硬件情况)
  • 版本化、灰度化(所有的软件都应该在线上有明确的版本,且上线过程是一点点灰度上)

更新nginx版本upstream升级http1.1解决多TIME_WAIT问题

前情提要

在使用java web container的时候,我们都在前面挡一层nginx,方便使用各种nginx的功能,设置成代理。 访问特别多的时候发现,服务器上存在大量的TIME_WAIT状态的连接。 经分析,可能是nginx早期版本的upstream还是使用的1.0的短连接代理,java container老是以1.0的方式主动断开进入TIME_WAIT状态,浪费了大量的连接。

过年十天技术阅读推荐汇总

春节期间收集的各种有意思的技术微博,这里是汇总帖。技术方向包括了分布式、开源、产品、关键领域,等等。排名不分先后。

  • @温高铁

各种数据库连接池性能对比 http://t.cn/zjVqSNg 结论:1) Druid是性能最好的数据库连接池,tomcat-jdbc和druid性能接近。2)proxool在激烈并发时会抛异常,完全不靠谱。 3) c3p0和proxool都相当慢,慢到影响sql执行效率的地步。4) bonecp性能并不优越,采用LinkedTransferQueue并没有能够获得性能提升

Disruptor Thrift Server连接参数与rps数值影响记录

disruptor thrift server

基础环境 rmbp
8G MEM
Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz 四核 八线程
oracle jdk 1.7.0_45

原理 如上图,是类似tomcat的nio实现过程,不过将queue换成了高性能的disruptor,可能会得到更好的性能。可调整参数为numAcceptors,numSelectors,numWorkersPerSelector三个值。
测试的代码位置在 https://github.com/54chen/disruptor_thrift_server 项目中的BenchmarkTest同时启动一个server,同时对其进行压测。