2017 JavaOne参会感想

国庆期间作为代表和另外 6 位同学去旧金山参加 JavaOne 大会,本次大会我关注的几个关键的 points:

  1. AJDK 在 Java 9 的 Keynote 主场公开亮相,Kingsum 为全场听众讲解了 AJDK 如何与 Intel 等硬件商场深度合作,支撑了双 11 全球最大的购物节。
  2. Java 9 的新特性,以模块化为代表。
  3. Serverless、Cloud Native 架构。
  4. 微服务和 DevOps 的结合。

下面记录一些感觉相对有启发的 info 带着我个人的一些想法:

继续阅读

2017QCon分享:从淘宝到云端的高可用架构演进

写在前面:由于QCon现场分享时间只有40分钟,所以和最初的slides相比后来缩减了2/3,因此下文可能看起来会比较『跳跃』。


大家好,我今天分享的题目是《高可用实践:从淘宝到上云的差异》,取这个标题是因为会涉及到两个方面内容,一方面以淘宝为例子,传统的IDC的时候,我们稳定性是怎么做的,另外在云计算背景下,有很多创业公司是基于阿里云这样的公有云基础设施做研发,在公有云的环境下怎么做好我们系统的高可用。 继续阅读

如何真实压测一个Web浏览型应用的性能

对于应用压测大家应该都有一些自己的方式,通常都是构造一些请求,不过构造请求学问就大了。

构造什么样的请求?构造的请求是否真实?构造的请求各种业务场景的配比?读写比例?

对于一个Web浏览型应用来说,相比对纯DB的压测,会更复杂一些,主要因为涉及缓存。 继续阅读

从一个开发的角度看负载均衡和LVS

在大规模互联网应用中,负载均衡设备是必不可少的一个节点,源于互联网应用的高并发和大流量的冲击压力,我们通常会在服务端部署多个无状态的应用服务器和若干有状态的存储服务器(数据库、缓存等等)。

一、负载均衡的作用

负载均衡设备的任务就是作为应用服务器流量的入口,挑选最合适的一台服务器,将客户端的请求转发给它处理,实现客户端到真实服务端的透明转发。最近几年很火的「云计算」以及分布式架构,本质上也是将后端服务器作为计算资源、存储资源,由某台管理服务器封装成一个服务对外提供,客户端不需要关心真正提供服务的是哪台机器,在它看来,就好像它面对的是一台拥有近乎无限能力的服务器,而本质上,真正提供服务的,是后端的集群。

一个典型的互联网应用的拓扑结构是这样的:

top 继续阅读

QCon2011大会4月8日PPT学习总结

最近正在召开QCon北京2011大会,趁此机会学习了一部分QCon大会的PPT,大会的PPT可以在QCon大会官网下载:http://www.qconbeijing.com/schedule.html

主题:淘宝商品库优化实践

讲师:淘宝核心系统数据库组 余锋(褚霸)

在技术方案的着眼点上,讲师主要强调了:通过高性能硬件支持平台,充分利用Cache(这一点在之后的演讲中多次强调),充分考虑容灾性。同时讲师表示要大胆借助开源产品提高系统性能

在I/O能力的分配上,提高读能力的方式是零散读,提高IOPS,对于提高写能力采用了集中写,提高吞吐量

在Cache分配上,商品库除了采用MySQL的内部存储、虚拟内存以外,还利用了Facebook的Flashcache技术(在文件系统和设备驱动之间新增一次缓存层,实现对热门数据的缓存,一般用SSD作为介质的缓存,通过将传统硬盘上的热门数据缓存到SSD上,然后利用SSD优秀的读性能,来加速系统)。这个方法较之内存缓存,没有内存快,但是可用空间可以比内存大很多。此外还利用了RAID卡内部Cache。

对于系统调优的指导思想,重视理论结合实际,不靠主观猜测而是按实际效果做决定。“内存为王”,用加大内存提升系统性能(其实也是间接加大了缓存)。随机数据和顺序数据分离,随机数据采用Direct IO(优点是CPU占用率小,适用于缓存命中率较低的文件),顺序数据通过缓存读。在保证安全的前提下,一定要充分利用系统各级的Cache

在业务上优化掉复杂查询(类似天涯论坛的做法)。对于InnoDB,分配尽可能大的Buffer Pool,日志数据分开存储,减少锁对多核CPU的影响(减小锁的开销),适时清除InnoDB产生的日志Cache。 继续阅读

高性能可伸缩系统构建的简要思想

为了支持高并发访问和海量数据的场景,在搭建应用时需要努力构建可伸缩的系统,这样在后期系统遇到瓶颈时可以简单地通过垂直伸缩或水平伸缩扩展系统。本文整理借鉴了林昊老师对构建可伸缩系统的文章。

一、垂直伸缩

垂直伸缩指通过增加或升级单台机器的硬件来获得对高并发访问和大数据量的更好支持。

1、支持高并发访问

可以增加CPU和内存,同时需要对系统进行一定调整,尽可能使得软件性能随硬件性能线性增长。

增加CPU时,需要进行如下调整:

首先需要减小锁的开销。当Java程序中线程比较多时,线程的上下文切换开销会增大,对锁的竞争也会变得更激烈,所以通常意义上线程并不是越多越好。当系统因为锁的竞争而导致CPU利用率较低时,可以采取以下策略减少锁带来的开销:

a、使用Java API中的并发类库

可以采用java.util.concurrent等包下面的并发类,通常它们已经经过了充分的优化,能有效地支持高并发环境下的操作,并发类中大量采用了非阻塞算法,有些利用了CAS实现无锁。这里有一个小提示:使用并发哈希表时应优先采用ConcurrentHashMap而不是Hashtable,前者通过分解锁的方法使得效率更高。 继续阅读