freyja v2 버 전 발표

전번 에 말 했다
freyja 는 orm, sharding, cache 에 다시 중심 을 둔다.
 
1. 더 완벽 한 orm
2. 응용 층 차단 의 바 텀 sharding
3. 응용 층 의 cache
그럼 바로 코드 를 넣 겠 습 니 다.
 
 
오픈 소스 경험 이 없어 서 프 리 지 아의 사상 과 코드 를 직접 소개 했다.
1. cache 부분 은 spring aop cache 로 직접 바 뀌 었 습 니 다.
 
spring cache 확장  
주석 몇 개 추가:
CacheDelete, CacheListReplace 등등...
현재 두 가지 문제 가 존재 합 니 다. 1. 스 레 드 가 안전 한 것 이 아 닙 니 다.2. 어떻게 하면 spring 의 cache 주해 처럼 스 캔 될 수 있 는 지 모 르 겠 습 니 다. http://www.iteye.com/problems/83419
 
 
또한, cache 는 free yja v2 와 아무런 관계 가 없다.
cache 의 소 개 는 약간 적 고 캐 시 는 상부 에 가 까 울 수록 효율 이 높다.그래서 기본적으로 freyja v1 의 캐 시 에 대한 이 해 를 포기 하고 상위 캐 시 로 바 꾸 었 습 니 다.
주 해 를 통 해 캐 시 관 계 를 유지 합 니 다.위의 spring cache 확장 은 실제로 전에 쓴 것 으로 현 재 는 이 를 크게 바 꾸 었 다.짝 퉁, spring 자체 cache 를 확장 하여 spel 표현 식 을 사용 합 니 다. CacheSave 라 는 주 해 는 약간 다 릅 니 다. key 는 반환 값 을 가 져 왔 습 니 다. 나중에 소 개 를 추가 할 것 입 니 다.
 
 
 
2、orm
orm 부분 은 자신의 annotation: @ Id, @ Column, @ Table, @ Transient 를 사용 하여 실체 와 표 의 관 계 를 표시 합 니 다.
 
orm 은 순수 jdbc 보다 지출 이 한 층 의 sql 분석 에 있 습 니 다. sql 분석 은 온도 가 적은 alibaba. druid 의 sql parser 부분 에 맡 겼 습 니 다.
(온 소 는 누구 입 니까?:http://code.alibabatech.com/wiki/dashboard.action）
해석 의 효율 이 매우 높 고 구체 적 으로 얼마나 높 은 지 나 는 구체 적 으로 테스트 한 적 이 없다.비용 이 아무리 많이 들 어도 프로젝트 에 있어 서 무시 할 수 있 는 비용 이 라 고 생각 합 니 다. 프로젝트 의 sql 은 모두 sql 을 미리 컴 파일 하기 때문에 이 층 이 캐 시 되 었 기 때문에 비용 은 무시 할 수 있 습 니 다.
 
orm 의 문법 은 이전 판 과 기본적으로 일치 합 니 다.
 
3、sharding
Freyja 2 버 전의 라 이브 러 리 시트 처리 방식  
 
sharding 부분 과 orm 은 기본적으로 아무런 관계 가 없 으 며, 이 부분 은 순수 sql 에 만 처 리 됩 니 다.저 는 freyja 의 sharding 방식 이 완벽 해 지 는 것 같 아 요.
freyja v2 의 sharding 은 @ SubColumn 에서 라 이브 러 리, 테이블 방식 을 결정 합 니 다. @SubColumn 은 이 필드 를 기준 으로 기록 을 구분 합 니 다.
 

	public DbResult getShardingTableName(Object value) {
		String tableName = getTableName();

		int hashCode = value.hashCode();
		if (hashCode < 0) {
			hashCode = -hashCode;
		}
		int dbNo = hashCode % ShardingUtil.engine.getDbNum();
		int tableNo = hashCode % ShardingUtil.engine.getTableNum();
		tableName = tableName + "_" + tableNo;
		return new DbResult(tableName, tableNo, dbNo);
	}

	public DbResult getShardingTableNameById(Object idValue) {
		String tableName = getTableName();
		if (idValue == null || !isSubTable()) {
			return new DbResult(tableName, -1, -1);
		} else {
			int n = (Integer) idValue / ShardingUtil.engine.getIdSubNum();
			int dbNo = n / ShardingUtil.engine.getTableNum();
			int tableNo = n % ShardingUtil.engine.getTableNum();
			tableName = tableName + "_" + tableNo;
			return new DbResult(tableName, tableNo, dbNo);
		}

	}

 
 
 
spring jdbc 의 AbstractRouting DataSource 와 결합 하여 다 중 데이터 소스 작업 환경 에 도달 합 니 다.
 
구체 적 으로 tuser 표 는 라 이브 러 리, 표 분할 작업 을 합 니 다.
1、

		<property name="jdbcTemplate" ref="jdbcTemplate" />
		<property name="packagesToScan" value="com.x.data.bean" />
		<property name="freyjaProperties">
			<value>
				show_sql=true
				db_num=2
				table_num=2
				id_sub_num=1000000
			</value>
		</property>
	</bean>

 
 db 설정num、table_num、id_sub_num
id_sub_num 은 매 표 용량 이 며, 별도로 표를 만 들 때 대응 하 는 자동 성장 시작 값 을 수정 해 야 합 니 다.
 

	<bean id="baseDataSource" parent="parentDataSource">
		<property name="url" value="${mysql.url}" />
		<property name="username" value="${mysql.user}" />
		<property name="password" value="${mysql.password}" />
	</bean>

	<bean id="dataSource" class="com.guyu.core.spring.datasource.DynamicDataSource">
		<property name="targetDataSources">
			<map key-type="java.lang.Integer">
				<entry key="0" value-ref="pu_game_0" />
				<entry key="1" value-ref="pu_game_1" />
			</map>
		</property>
		<property name="defaultTargetDataSource" ref="baseDataSource" />
	</bean>

 

	<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
		<property name="dataSource" ref="dataSource" />
	</bean>

 
 
2. User 실체 에 @ Table (name = "t user", isSubTable = true) 을 추가 해 야 합 니 다.
 이 시 계 를 표시 하려 면 절 분 이 필요 하 다.
3、 @Column(name = "open_id")

@SubColumn(isSubColumn = true)
private String openId;

 
그 중 하 나 를 선택 하여 SubColumn 으로 표시 해 야 합 니 다.
 
 
sharding 은 순수 jdbc 를 대상 으로 합 니 다. 관심 있 는 것 은 druid 의 sql parser (ps: 자료 가 적 습 니 다) 를 연구 할 수 있 습 니 다.
 
기타 보충:
1. 왜 free yja 1 과 2 는 모두 spring jdbc 를 사용 합 니까?
특별한 이유 없 이 히 베 네 이 트 를 사용 해 왔 지만 먼저 접촉 한 spring jdbc 는 괜 찮 으 면 사용 했다.또한 spring jdbc 자체 가 orm 에 가 까 워 개조 했다.
2、druid
freyja v1 을 할 때 실제로 druid 의 sql parser 기능 을 알 고 있 었 지만 외국인 jsqlparser 가 일찍 나 와 서 쓰 는 사람 이 많 으 면 좋 을 것 같 아서 jsqlparser 를 사용 했다.
나중에 v2 를 하면 서 sharding 기능 을 발전 시 켰 을 때 온 소 에 게 연락 을 했 는데 그 는 나 에 게 sql parser 를 보 여 주 었 다.결 과 는 정말 대단 하 다.sql parser 는 무엇 을 원 하 는 지, 예 를 들 어 orm 부분 sql parser 는 직접 지원 하고 매우 편리 합 니 다.문제 가 좀 있 었 지만 온 소 에 게 피드백 을 주 고 는 금방 해 결 됐 습 니 다.sharding 기능 도 교류 과정 에서 생 긴 것 이다.
첨부 파일 의 압축 패키지 의 druid0.2.11111. jar 는 sharding 지원 을 포함 하 는 버 전 입 니 다.druid 의 최신 버 전이 이 부분 을 포함 하고 있 는 지 모 르 겠 습 니 다.
 
대량의 테스트 테스트 테스트 와 테스트 가 필요 합 니 다. 현재 free yja v2 는 프로젝트 에 사용 되 고 있 으 며 복구 와 추가 가 필요 한 기능 은 실제 응용 에 따라 달라 집 니 다.
 
 
cache, orm, sharding 부분의 실현 방향 에 대해 토론 하 시기 바 랍 니 다!