java程序员5年后的技术思考(2018)

5年前,做的项目只在单机上运行，数据量不大，3大框架+一个数据库是标配

5年后,项目集群部署,数据量大，编程中要考虑分布式锁，分库，缓存等。考虑项目时，需要加入新的元素,势必也会引入新的问题

现在开发中,哪些想法是标配呢?

#分布式锁

锁存在的意义是控制对共享资源的访问,共享资源主要有类变量、数据库、硬件资源等。现在编程中,类变量已经用的很少了

单机运行时,javaapi可以实现锁(允许同一时间只有一个方法在执行)

集群部署javaapi就无能为力,毕竟javaapi在不同机器或jvm上运行，两者没有联系

至于分布式锁的场景，在编写的带有关键词synchronized的代码，严格意义上,基本都需要由分布式锁替代.在一般的大企业的应用中,基本都是集群部署。

基于分布式锁有3种实现方式:
1.基于数据库的锁机制
1.1 通过插入一条满足唯一性的记录实现分布式锁
1.2 通过数据库中预设的记录实现排他锁(for update-行级锁，前提是过滤的字段有唯一性索引，要不然就不能叫行级锁了)
springquartz就是通过这种方法实现的

这个是数据库悲观锁，其实还有一种乐观锁。比较典型的例子是svn提交，都可以提交，失败就回滚

2.基于缓存redis的锁机制

做的业务场景比较简单，所以很少用到redis锁,实在想不出分布式锁主要用在哪些地方。只能说贫(业)穷(务)限制了我对锁的想象力

锁->资源->数据库：什么数据库资源只能同时一个人访问,可能在秒杀活动能遇到(同一时间,万级别的人抢几件商品)

加锁：

public class RedisTool {
 
    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";
 
    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
 
        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
 
        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;
 
    }
 
}

解锁:

public class RedisTool {
 
    private static final Long RELEASE_SUCCESS = 1L;
 
    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {
 
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
 
        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;
 
    }
 
}

引用：
Redis 分布式锁的正确实现方式（ Java 版）
http://www.importnew.com/27477.html

3.基于zookeeper的锁机制

数据库锁：sql

redis锁:jedis api+redis服务器( 原理同数据库分布式锁)

zookeeper锁:curator api+zookeeper服务器

#缓存
对于一些简单的应用或场景或业务，直接查询数据库就能解决问题。再复杂一点也是用到第三方缓存组件

对于一些比较复杂的场景或业务，就要借助缓存服务器解决响应慢的问题

现在比较火的就是redis

在一般的企业级应用中,也就是用hashmap或list这样的类变量做为简单的缓存。就算是负载均衡部署,几个应用都从数据库中加载数据，只要数据不变也不会有多大问题。但是对于大型分布式应用，对数据的一致性要求比较高，这时候第三方缓存服务器就有用武之地了。

对于系统中,通过类变量hashmap或list来存储缓存数据的.用户量增加,分布式部署时，都可以通过redis替换

redis可用于解决tomcat启动过程中的session丢失问题

以获取最近25条评论为例

@Test
	public void test0() {
		String key = "latest.comments";
		// 准备初始化数据
		ListOperations<Serializable, Object> listOp = redisTemplate.opsForList();

		for (int i = 1; i <= 100; i++) {
			listOp.leftPush(key, i);
		}

		// 最近的25条记录
		listOp.trim(key, 0, 25);
		
		// 查询最近10条记录
		int startPage = 3;
		int nums = 10;
		List<Object> list1 = listOp.range(key, (startPage - 1)*nums, startPage*nums -1);
		if (null != list1 && list1.size() == nums) { // 全部在缓存中
			for (int i = 0; i < list1.size(); i++) {
				System.out.println(list1.get(i));
			}
		} else {
			System.out.println("查询数据库获取历史记录");
		}
		
	}

#对外接口设计
对于一个有价(liu)值(liang)的业务,不仅要能提供直接浏览器访问，更需要提供可供其他系统调用的接口。怎么设计这些接口呢

2个层面考虑：
1.技术选型
http,hessian,netty,mq

2.流量控制

#配置文件
项目集群或分布式部署，配置文件中参数太多，重新部署太耗费时间或直接在运行项目中修改，地方太多。

更明确的方法是有一个配置管理系统

在spring项目中,通过覆盖属性配置类，启动应用时，调用配置系统设置参数。

#单点登录

#分库分表机制

可以从2个方面考虑：
1.DB集群配置
2.代码实现
spring环境中,多数据源的核心类是AbstractRoutingDataSource.

import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;

public class DynamicRoutingDataSource extends AbstractRoutingDataSource {

	@Override
	protected Object determineCurrentLookupKey() {
		return DbRouterLocalContext.getDbKey();
	}

}

获取当前环境数据源

public class DbRouterLocalContext {
	private static final ThreadLocal<String> dbKeyLocal = new ThreadLocal<String>();
	
	private static final ThreadLocal<String> tblKeyLocal = new ThreadLocal<String>();
	
	public static void setDbKey (String dbIdx) {
		dbKeyLocal.set(dbIdx);
	}
	
	public static String getDbKey() {
		return dbKeyLocal.get();
	}
	
	public static void setTblKey (String tblIdx) {
		tblKeyLocal.set(tblIdx);
	}
	
	public static String getTblKey() {
		return tblKeyLocal.get();
	}
}

当前环境使用数据库的配置，一般在dao层设置.根据传入的id或其他值设置规则，应该传入哪个数据库。此时将涉及spring aop的编写

基本思路：
定义切面aspect,定义连接点pointcut(结合注解)

xml中配置：
数据库操作模板中,设置dyDataSource

<bean id="dyDataSource" class="com.byron.sharding.router.DynamicRoutingDataSource">
		<property name="targetDataSources">
	        <map>
	             <entry key="db1" value-ref="dataSource01" /> 
	             <entry key="db2" value-ref="dataSource02" /> 
	             <entry key="db3" value-ref="dataSource03" /> 
	        </map>
    	</property>
    	<property name="defaultTargetDataSource" ref="dataSource01" />
	</bean>

参考：
http://flysoloing.github.io/2015/09/20/spring-database-sharding-practice/

#文件服务器

不要脱离业务学习技术，学习新技术同时学习新业务场景，即使这些场景你用不到

java程序员5年后的技术思考(2018)

猜你喜欢