征服 Kestrel + XMemcached + Spring TaskExecutor

上一篇征服 Kestrel + XMemcached只是对Kestrel操作做了简要的整理，如果要在实际工作用应用，还需要对接收端继续改造，这里需要用到Spring的Executor以线程池的方式，作为Kestrel的Worker，完成具体的业务操作。

相关链接：
征服 Kestrel
征服 Kestrel + XMemcached

如何理解Executor?

• The Endless Task，任务是永远做不完的，需要进行细化分解，具体工作交给Worker来做。
• 那何为Worker呢？这里就是真正做工的进程，具体来讲就是处理业务逻辑、数据库操作等等，诸如此类的动作。
• 试想，如果只有一个Worker工作，那效率势必低下。于是通过多线程复制Worker，增加同时工作的Worker数量。换句话说，一个Worker就是一个Thread。
• 这时候，如果来了新的任务该怎么办？排队等着！
• 如果，如果队列满了怎么办，抛出异常。然后？你看着办！调整线程数/队列数，做集群等等，随你扩展！

现学现卖，简单说下Executor。
Executor，即JDK 5.0才有的java.util.concurrent.Executor接口，主要目的是将“任务提交”与“任务执行”分离解耦。
这个接口只有 void execute(Runnable command)这个方法，用于执行任务。
Spring提供了与之等同的TaskExecutor接口（org.springframework.core.task.TaskExecutor），拥有统一个方法。但提供多种实现类。

引用

SimpleAsyncTaskExecutor类

这个实现不重用任何线程，或者说它每次调用都启动一个新线程。但是，它还是支持对并发总数设限，当超过线程并发总数限制时，阻塞新的调用，直到有位置被释放。如果你需要真正的池，请继续往下看。

SyncTaskExecutor类

这个实现不会异步执行。相反，每次调用都在发起调用的线程中执行。它的主要用处是在不需要多线程的时候，比如简单的test case。

ConcurrentTaskExecutor类

这个实现是对Java 5 java.util.concurrent.Executor类的包装。有另一个备选, ThreadPoolTaskExecutor类，它暴露了Executor的配置参数作为bean属性。很少需要使用ConcurrentTaskExecutor, 但是如果ThreadPoolTaskExecutor不敷所需，ConcurrentTaskExecutor是另外一个备选。

SimpleThreadPoolTaskExecutor类

这个实现实际上是Quartz的SimpleThreadPool类的子类，它会监听Spring的生命周期回调。当你有线程池，需要在Quartz和非Quartz组件中共用时，这是它的典型用处。

ThreadPoolTaskExecutor类

它不支持任何对java.util.concurrent包的替换或者下行移植。Doug Lea和Dawid Kurzyniec对java.util.concurrent的实现都采用了不同的包结构，导致它们无法正确运行。

这个实现只能在Java 5环境中使用，但是却是这个环境中最常用的。它暴露的bean properties可以用来配置一个java.util.concurrent.ThreadPoolExecutor，把它包装到一个TaskExecutor中。如果你需要更加先进的类，比如ScheduledThreadPoolExecutor,我们建议你使用ConcurrentTaskExecutor来替代。

TimerTaskExecutor类

这个实现使用一个TimerTask作为其背后的实现。它和SyncTaskExecutor的不同在于，方法调用是在一个独立的线程中进行的，虽然在那个线程中是同步的。

WorkManagerTaskExecutor类

CommonJ 是BEA和IBM联合开发的一套规范。这些规范并非Java EE的标准，但它是BEA和IBM的应用服务器实现的共同标准

这个实现使用了CommonJ WorkManager作为其底层实现，是在Spring context中配置CommonJ WorkManager应用的最重要的类。和SimpleThreadPoolTaskExecutor类似，这个类实现了WorkManager接口，因此可以直接作为WorkManager使用。

我们可以先不关注这么一堆具体的实现类，回到本帖问题本身——实现一个多线程式的Worker实现。
先配置一个TaskExecutor的是执行者，这里控制线程池活跃线程数为1，最大线程数为5；任务队列长度为10。

	<!-- pool-size="1-5"，线程池初始的线程数为1，最大活跃线程数为5 
	         最大值可理解为可用的数据库连接数-->
	<!-- queue-capacity="10"，任务队列长度。 -->
	<task:executor
		id="kestrelExecutor"
		pool-size="1-5"
		queue-capacity="10" />

这段配置的具体实现类是org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor，其含义是：提供1～5个线程，用于任务处理，当这些线程都在工作时，新来的任务就存放到队列中，如果新进任务数超过了队列长度，就会抛出异常（org.springframework.core.task.TaskRejectedException）。意思就是说Worker数不够，需要增加pool-size数量！
建议捕获该异常，日志监控/邮件告警。

注意Active数量，如果是数据库操作，这里的Active一定要小于等于数据库可用连接数量。

实现类就就极为简单了：

import javax.annotation.Resource;

import org.apache.log4j.Logger;
import org.springframework.core.task.TaskExecutor;
import org.springframework.stereotype.Component;

/**
 * Worker
 * 
 * @author zlex
 * @version 1.0
 * @since 1.0
 */
@Component
public class KestrelExecutorWorker {
	/**
	 * Logger for this class
	 */
	private static final Logger logger = Logger
			.getLogger(KestrelExecutorWorker.class);

	@Resource
	private TaskExecutor kestrelExecutor;

	/**
	 * 业务处理
	 * 
	 * @param value
	 */
	public void process(final Object value) {
		kestrelExecutor.execute(new Runnable() {
			public void run() {
				logger.debug(value);
			}
		});
	}

}

在上一篇代码的基础上修改，做一个测试用例：

import static junit.framework.Assert.*;

import net.rubyeye.xmemcached.MemcachedClient;

import org.junit.Before;
import org.junit.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.core.task.TaskRejectedException;

/**
 * WorkerTest
 * 
 * @author zlex
 * @version 1.0
 * @since 1.0
 */
public class KestrelExecutorWorkerTest {

	private ApplicationContext app;
	private KestrelExecutorWorker kestrelExecutorWorker;
	private MemcachedClient memcachedClient;

	private final static String QUEUE_NAME = "KQ";

	/**
	 * @throws java.lang.Exception
	 */
	@Before
	public void before() throws Exception {
		app = new ClassPathXmlApplicationContext("applicationContext.xml");
		memcachedClient = (MemcachedClient) app.getBean("memcachedClient");
		kestrelExecutorWorker = (KestrelExecutorWorker) app
				.getBean("kestrelExecutorWorker");
	}

	@Test
	public void test() {
		// The Endless Task
		while (true) {
			try {
				Object value = (Object) memcachedClient.get(QUEUE_NAME);
				if (value != null) {
					// Process...
					kestrelExecutorWorker.process(value);
				} else {
					// Sleep...
					Thread.sleep(300);
				}
			} catch (TaskRejectedException e) {
				// Send Mail To System Administrator
				e.printStackTrace();
				fail(e.getMessage());
			} catch (Exception e) {
				e.printStackTrace();
				fail(e.getMessage());
			}
		}
	}
}

这时，Main线程会一直跑下去，等待任务分配，或者任务后，进行业务处理。这里是将获得的数据打印日志。

如何模拟一个队列爆满的情况？

	<task:executor
		id="kestrelExecutor"
		pool-size="1-2"
		queue-capacity="1" />

这个配置，足以抛出org.springframework.core.task.TaskRejectedException

引用

org.springframework.core.task.TaskRejectedException: Executor [java.util.concurrent.ThreadPoolExecutor@551748e6[Running, pool size = 2, active threads = 0, queued tasks = 1, completed tasks = 633]] did not accept task: org.zlex.kestrel.executor.KestrelExecutorWorker$1@5e53e1f3

此致，代码详见附件！

有关Kestrel+Xmemcached的任何问题，还是看看作者怎么总结的！！！
Xmemcached的FAQ和性能调整建议


相关链接：
征服 Kestrel
征服 Kestrel + XMemcached
征服 Kestrel + XMemcached + Spring TaskExecutor

评论

5 楼 di1984HIT 2014-04-14  

挺好的，前沿的用的不错啊

4 楼 snowolf 2012-07-30  

jinnianshilongnian 写道

snowolf 写道

jinnianshilongnian 写道

现在用Kestrel 挺多的，你们现在也在用吗？

刚完成选型，这就开始尝试。

呵呵，方便问下用到什么场景嘛

举个最简单的例子，Kestrel是Twriter的产物，这里只说写操作，如果多个用户同时发了一条微博，后台数据库即便是再多集群，也无法再一秒内完成所有数据库操作。这时候，如何在不增加硬件成本的基础上，最大范围提升系统利用率？就是让这些非及时响应的操作异步完成。把写操作放到队列里，慢慢处理。当然，这里要考虑一些问题：1.队列操作是否会丢失消息？ 2.用户操作后如何及时浏览自己的微博？问题1，kestrel通过日志，队列标志等等方面完善了这一点，即便是队列服务重启，也不会丢失消息；问题2，通过缓存方式，将原本要写数据库的操作，同时写在用户缓存中，提升用户体验。
貌似就是这些！

3 楼 jinnianshilongnian 2012-07-30  

snowolf 写道

jinnianshilongnian 写道

现在用Kestrel 挺多的，你们现在也在用吗？

刚完成选型，这就开始尝试。

呵呵，方便问下用到什么场景嘛

2 楼 snowolf 2012-07-30  

jinnianshilongnian 写道

现在用Kestrel 挺多的，你们现在也在用吗？

刚完成选型，这就开始尝试。

1 楼 jinnianshilongnian 2012-07-30  

现在用Kestrel 挺多的，你们现在也在用吗？