架构高性能海量图片服务器的技术要素 - 北游运维 - 开源中国社区
在笔者的另一篇文章《nginx性能改进一例》有讲到，在图片规模比大的情况，nginx处理能力受制于文件系统的io，意味着，在大规模图片的场景，如果运维还依旧采用传统文件系统的方式，无论是备份成本，还是前端成本，将是无法去衡量，不要去指望调优一点文件系统的一些参数，能带来多大的性能收益，也不要去目录hash+rewrite的方式，改进不大，因为新版的文件系统默认开启了dir_index，解决了同一个目录下文件过多而过慢的问题。不过还有一种方案就是采购SSD盘、fusion-io卡之类高性能的硬件去解决随机io，当然你得容忍备份的痛苦。
先看一下架构图逻辑图，这也是现在各大公司采用的方式。
这个是一个大致逻辑图，具体布署是根据模块的性能消耗类型去混合部署。
第一点，分布存储的必要性：存储原始图片，用分布式存储有几个好处，分布式能自动提供冗余，不需要我们去备份，担心数据安全，在文件数量特别大的情况下，备份是一件很痛苦的事情，rsync扫一次可能是就是好几个小时。还有一点就是分布式存储动态扩容方便。不过唯一遗憾的是目前适合于存小文件系统比较少，我了解的只有fastdfs，以及淘宝的tfs，还有mongodb这几个，tfs经历过淘宝那种规模的考验，文档和工具都太少，如果能驾驭tfs，我觉得值得尝试一下。。
第二点，上传和下载分开处理：通常图片服务器上传的压力与下载的压力相差很大，大多数的公司都是下载的压力是上传压力的n倍。业务逻辑的处理也区别明显，上传服务器对图片重命名，记录入库信息，下载服务器对图片添加水印、修改尺寸之类的动态处理。从数据的角度，我们能容忍部分图片下载失败，但绝不能有图片上传失败，因为上传失败，意味着数据的丢失。上传与下载分开，能保证不会因下载的压力影响图片的上传，而且还有一点，下载入口和上传入口的负载均衡策略也不同，下面有说明。
第三点，使用cache做缓层：分布式存储解决了存储安全问题，但性能问题还需要用cache去解决，直接从分布式存储取文件给用户提供服务，每秒的request高不到哪里去，像淘宝之类的网站，都做了二层cache。对于cache的开源软件选型要考虑二点，1，缓存的量级大，尽可能让热点图片缓存在cache中，像varnish之类的，纯内存的cache，虽然性能很好，但能cache的量级很限于内存，用来做图片的缓存不太适合；2，避免文件系统式的缓存，在我的另一篇文章中有测过，在文件量非常的情况下，文件系统的型能很差，像squid,nginx的proxy_store,proxy_cache之类的方式缓存，当缓存的量级上来后，性能将不能满足要求。开源的traffic server直接用裸盘缓存，是一个不错的选择，当然使用leveldb之类的做缓存，我估计也能达到很好的效果。这里说明一下cache缓存最好不要去依赖第三方CDN，现在很多第三的CDN业务，不仅提供内容分发外，还额外提供第一个二级缓存之类的服务，但这里面就一个最大的风险就是如果第三调整带来的回源压力暴增，此时你的架构能否支撑，需要认真评估一下，如果成本允许，服务控制在自己手中最靠谱。
第四点，使用一致性哈希（consistent hashing）做下载负载均衡：虽公司的业务的增加带来流量的增加，一个阶段后，一个cache通常不能解决问题，这时扩容cache就是常做的一件事，传统的哈希不足就是每扩容一次，哈希策略将重新分配，大部分cache将失效，带来的问题是后端压力暴增。对uri进行一性能哈希负载均衡，能避免增加或者减少cache引起哈希策略变化，目前大多开源的负载均衡软件都有这个功能，像haproxy都有，至于一致性哈希的最优化，可以参考一下下图(摘自网上的一张图，表示的是怎样的物理节点和虚拟节点数量关系，哈希最均匀)。
第五点，利用CDN分发和多域名访问入口：想要获得好的用户体验，利用CDN的快速分发是有必要的，从成本上考虑可以购买使用第三方的CDN平台。多域名访问方式，大多的浏览器都对单个域名进行了线程并发限制，采用多域名能够加快图片展示的速度。
关于图片服务器的部署基本算完了，其它的细节性调优这里就不说明了。
大数据处理系列之（一）Java线程池使用 - cstar（小乐） - 博客园
ThreadPoolExecutor有界队列使用
public class ThreadPool {
private final static String poolName = "mypool";
static private ThreadPool threadFixedPool = null;
public ArrayBlockingQueue<Runnable> queue = new ArrayBlockingQueue<Runnable>(2);
private ExecutorService executor;
static public ThreadPool getFixedInstance() {
return threadFixedPool;
}
private ThreadPool(int num) {
executor = new ThreadPoolExecutor(2, 4,60,TimeUnit.SECONDS, queue,new DaemonThreadFactory
(poolName), new ThreadPoolExecutor.AbortPolicy());
}
public void execute(Runnable r) {
executor.execute(r);
}
public static void main(String[] params) {
class MyRunnable implements Runnable {
public void run() {
System.out.println("OK!");
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
int count = 0;
for (int i = 0; i < 10; i++) {
try {
ThreadPool.getFixedInstance().execute(new MyRunnable());
} catch (RejectedExecutionException e) {
e.printStackTrace();
count++;
}
}
try {
log.info("queue size:" + ThreadPool.getFixedInstance().queue.size());
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("Reject task: " + count);
}
}
首先我们来看下这段代码几个重要的参数，corePoolSize 为2，maximumPoolSize为4，任务队列大小为2，每个任务平
均处理时间为10ms,一共有10个并发任务。
执行这段代码，我们会发现，有4个任务失败了。这里就验证了我们在上面提到有界队列时候线程池的执行顺序。当新任务在
方法 execute(Runnable) 中提交时， 如果运行的线程少于 corePoolSize，则创建新线程来处理请求。 如果运行的线程多于
corePoolSize 而少于 maximumPoolSize，则仅当队列满时才创建新线程，如果此时线程数量达到maximumPoolSize,并且队
列已经满，就会拒绝继续进来的请求。
现在我们调整一下代码中的几个参数，将并发任务数改为200，执行结果Reject task: 182，说明有18个任务成功了，线程处理
完一个请求后会接着去处理下一个过来的请求。在真实的线上环境中，会源源不断的有新的请求过来，当前的被拒绝了，但只要线
程池线程把当下的任务处理完之后还是可以处理下一个发送过来的请求。
通过有界队列可以实现系统的过载保护，在高压的情况下，我们的系统处理能力不会变为0，还能正常对外进行服务，虽然有些服
务可能会被拒绝，至于如何减少被拒绝的数量以及对拒绝的请求采取何种处理策略我将会在下一篇文章《系统的过载保护》中继续
阐述。
参考文献：
- ThreadPoolExecutor使用与思考（上）-线程池大小设置与BlockedQueue的三种实现区别 http://dongxuan.iteye.com/blog/901689
- ThreadPoolExecutor使用与思考（中）-keepAliveTime及拒绝策略http://dongxuan.iteye.com/blog/902571
- ThreadPoolExecutor源代码
- Java线程池介绍以及简单实例 http://wenku.baidu.com/view/e4543a7a5acfa1c7aa00cc25.html
kettle中通过 时间戳（timestamp）方式 来实现数据库的增量同步操作（一） - Armin - 博客园
这个实验主要思想是在创建数据库表的时候，
通过增加一个额外的字段，也就是时间戳字段，
例如在同步表 tt1 和表 tt2 的时候，
通过检查那个表是最新更新的，那个表就作为新表，而另外的表最为旧表被新表中的数据进行更新。
实验数据如下：
mysql database 5.1
test.tt1( id int primary key , name varchar(50) );
mysql.tt2( id int primary key, name varchar(50) );
快照表，可以将其存放在test数据库中，
同样可以为了简便，可以将其创建为temporary 表类型。
数据如图 kettle-1
kettle-1
============================================================
主流程如图 kettle-2
kettle-2
在prepare中，向 tt1，tt2 表中增加 时间戳字段，
由于tt1，tt2所在的数据库是不同的，所以分别创建两个数据库的连接。
prepare
kettle-3
在执行这个job之后，就会在数据库查询的时候看到下面的字段：
kettle-4
然后， 我们来对tt1表做一个 insert 操作 一个update操作吧~
kettle-5
在原表上无论是insert操作还是update操作，对应的updateTime都会发生变更。
如果tt1 表 和 tt2 表中 updateTime 字段为最新时间的话，则说明该表是新表 。
下面只要是对应main_thread的截图：
kettle-6
在这里介绍一下Main的层次：
Main
START
Main.prepare
Main.main_thread
{
START
main_thread.create_tempTable
main_thread.insert_tempTable
main_thread.tt1_tt2_syn
SUCCESS
}
Main.finish
SUCCESS
在main_thread中的过程是这样的：
作为一个局部的整体，使它每隔200s内进行一次循环，
这样的话，如果在其中有指定的表 tt1 或是 tt2 对应被更新或是插入的话，
该表中的updateTime字段就会被捕捉到，并且进行同步。
如果没有更新出现，则会走switch的 default 路线对应的是write to log.
继续循环。
首先创建一个快照表，然后将tt1，tt2表中的最大(最新)时间戳的值插入到快照表中。
然后，通过一个transformation来判断那个表的updateTime值最新，
来选择对应是 tt1表来更新 tt2 还是 tt2 表来更新 tt1 表；
main_thread.create_tempTable.JOB:
main_thread.insert_tempTable.Job:
PS： 对于第二个SQL 应该改成(不修改会出错的)
set @var1 = ( select MAX(updatetime) from tt2);
insert into test.temp values ( 2 , @var1 ) ;
因为conn对应的是连接mysql（数据库实例名称），
但是我们把快照表和tt1 表都存到了test（数据库实例名称）里面。
在上面这个图中对应的语句是想实现，在temp表中插入两行记录元组。
其中id为1 的元组对应的temp.lastTime 字段 是 从tt1 表中选出的 updateTime 值为最新的，
id 为2的元组对应的 temp.lastTime 字段 是 从 tt2 表中选出的 updateTime 值为最新的 字段。
当然 ， id 是用来给后续 switch 操作提供参考的，用于标示最新 updateTime 是来自 tt1 还是 tt2，
同样也可以使用 tableName varchar(50) 这种字段 来存放 最新updateTime 对应的 数据库.数据表的名称也可以的。
main_thread.tt1_tt2_syn.Transformation:
首先，创建连接 test 数据库的 temp 表的连接，
选择 temp表中 对应 lastTime 值最新的所在的记录
所对应的 id 号码。
首先将temp中 lastTime 字段进行 降序排列，
然后选择id ， 并且将选择记录仅限定成一行。
然后根据id的值进行 switch选择。
在这里LZ很想使用，SQL Executor，
但是它无法返回对应的id值。
但是表输入可以返回对应的id值，
并被switch接收到。
下图是对应 switch id = 1 的时候：即 tt1 更新 tt2
注意合并行比较 的新旧数据源 的选择
和Insert/Update 中的Target table的选择
下图是对应 switch id = 2 的时候：即 tt2 更新 tt1
注意合并行比较 的新旧数据源 的选择
和Insert/Update 中的Target table的选择
但是考虑到增加一个 column 会浪费很多的空间，
所以咋最终结束同步之后使用 finish操作步骤来将该 updateTime这个字段进行删除操作即可。
这个与Main中的prepare的操作是相对应的。
Main.finish
这样的话，实验环境已经搭建好了，
接下来进行，实验的数据测试了，写到下一个博客中。
当然，触发器也是一种同步的好方法，写到后续博客中吧~
时间戳的方式相比于触发器，较为简单并且通用，
但是 数据库表中的时间戳字段，很费空间，并且无法对应删除操作，
也就是说 表中删除一行记录， 该表应该作为新表来更新其余表，但是由于记录删除 时间戳无所依附所以无法记录到。