Jedis Sharding实现

随着业务的发展,当Redis单实例无法满足需求时,无可避免的要采用Redis集群方案。

目前普遍采用的Redis集群方案有:

  • 客户端做Sharding;
  • twenproxy;
  • redis cluster

Jedis sharding实现逻辑:https://github.com/jjmatrix/doraemon/tree/v2.1.0/doraemon-cache/src/main/java/org/jmatrix/cache/redis

 

Posted in Redis | Leave a comment

从Tomcat无法正常关闭讲讲Java线程关闭问题

正常情况下,会优先采用catalina.sh stop来停止Tomcat实例,这样可以让服务有机会处理完请求,并做好善后工作。 但如果通过catalina.sh stop命令无法关闭Tomcat实例,则只能kill -9了。

 

为什么在给Tomcat发出stop命令以后,Tomcat实例无法关闭?

 

可能有两种原因:

  • Tomcat的主线程没有结束(也即main函数没有执行结束);
  • Tomcat中启动的webapps有非daemon线程阻止了Tomcat进程的关闭;

 

第一种情况,如果发出stop命令以后,Tom[......]

Read more

Posted in 日常文章 | Tagged , | 评论关闭

Junit4:参数化测试

(注意,我要用官方文档开始刷存在感了…)

Junit通过自定义runner——Parameterized来实现参数化测试,参数化测试主要用于需要重复测试不同条件的场景,举个栗子:

public class Fibonacci {
    public static int compute(int n) {
        int result = 0;

        if (n <= 1) {
            result = n;
        } else {
            result = compute(n - 1) + comp[......]

Read more

Posted in 译文 | Tagged | Leave a comment

Junit4:测试方法执行顺序

(注意,我要用官方文档开始刷存在感了…)

在之前的版本中,Junit在设计上并没有指定测试方法的执行顺序,方法的调用就是根据reflection api的返回顺序。鉴于Java平台并没有规定一个特定的顺序,甚至其返回的顺序有一定的随机性,依赖于JVM的顺序非常的不明智。

 

当然,编写良好的测试用例是不应该依赖于测试方法的执行顺序的。但万一存在这样的情况呢?这个时候“确定顺序”带来的可预测的测试失败总是好过随机的测试失败。

 

从4.11版本开始,Junit将默认使用一种确定性的顺序,也即MethodSorters.DEFAULT。如果想改变测[......]

Read more

Posted in 日常文章 | Tagged | Leave a comment

Junit4:异常测试

(注意,我要用官方文档开始刷存在感了…)

有些时候,单元测试中需要验证抛出的异常是否是期望得到的,抑或验证抛出异常的message等信息。

这如果是在junit3,一般会通过try catch来处理,在catch中判断异常类型,抑或比较message值。

当然,这一点都不优雅,不但要多谢许多代码,测试用例中充斥的try catch也非常不好看。到了junit4,junit提供了新的方式来支持异常测试。

 

<1> 在@Test中通过expected指定测试的异常类,如:

@Test(expected = IllegalArgumentE[......]

Read more

Posted in 日常文章 | Tagged | Leave a comment

Dubbo走读——ExtensionLoader(服务发现)

JAVA提供的服务发现

 

Java1.6开始通过ServiceLoader提供了一种服务发现机制,通过它可以自由选择自己的服务实现。其工作原理是,通过扫描/META-INF/services/下以服务名称(类名称)命名的文件找到对应的服务实现,ServiceLoader返回的是Iterator,如果有多个,则需要由使用方做选择。

 

JDK中有一些实现就用了这种服务发现机制,像SelectorProvider在创建provider的过程中,会通过ServiceLoader去寻找provider的实现,如:

private static boolea[......]

Read more

Posted in 日常文章 | Tagged | Leave a comment

dubbo-rpc请求处理流程 client端

获取reference对象

假设我们采用Spring配置,那么我们使用的是ReferenceBean,从ReferenceBean继承自FactoryBean我们知道对于这么一个reference配置:

<dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" />

当引用这个bean时,是通过ReferenceBean的getObject()方法。它的实现很简单,直接调ReferenceConfig的get()方法,[......]

Read more

Posted in 日常文章 | Tagged | Leave a comment

dubbo-负载均衡

1. 一些相关的概念

<1> 服务sticky(服务黏性),类似让客户端的请求总是分发到同一台服务器。

如nginx中可以支持session sticky,通过ip_hash实现客户端的请求总是分发到同一个服务器。 有时候网站或系统经常是与session有关的,需要用sessionid或cookie来识别用户验证用户。

 

2. 实现原理

dubbo官方文档中对负载均衡扩展的说明有:

(1) 扩展说明:

从多个服务提者方中选择一个进行调用。

(2) 扩展接口:

com.alibaba.dubbo.rpc[......]

Read more

Posted in 日常文章 | Tagged | Leave a comment

Java那点事——异步

在JDK1.6提供了Future,FutureTask,ExecutorService等用于支持异步编程,但是Future,FutureTask没有提供callback机制,只能主动轮询,通过get去获取结果。

 

Guava的ListenableFuture对此做了扩展,支持callback机制。

 

就callback机制的扩展而言,也并不复杂。看看ListenableFuture与ListenableFutureTask:
public interface ListenableFuture extends Future {
  void add[......]

Read more

Posted in Java | Leave a comment

Tomcat源码走读——session管理(续)

2. session创建、过时处理等

public Session createSession(String sessionId ) {

        if ((maxActiveSessions &gt;= 0) &amp;&amp;
                (getActiveSessions() &gt;= maxActiveSessions)) {
            rejectedSessions++;
            throw new TooManyActiveSessionsException([......]

Read more

Posted in J2EE | Tagged | Leave a comment
« Older