aa87963014
- 浏览: 154359 次
- 性别:
- 来自: 布尼塔尼亚
-
最新评论
-
aa87963014：
iTarget 写道弄清楚“事务”和“事物”打错字, 统一为事 ...
现在的数据库系统是否还需要事务？ -
iTarget：
弄清楚“事务”和“事物”
现在的数据库系统是否还需要事务？ -
aa87963014：
ipconfig1 写道 我现在也遇到这样的问题，当缓存的数据 ...
spring cache 拓展 -
aa87963014：
xcw931924821 写道楼主现在实现了吗？可以查看我的 ...
spring cache 拓展 -
xcw931924821：
楼主现在实现了吗？
spring cache 拓展
文章列表
用到了mysql ignore 解决一些问题
- 博客分类：
- 随便记点东西
insert ignore into UserProperty(uid,pid,num) (select id,?,? from User);
ignore 就是忽略错误
在我想给UserProperty表修改num字段的时候遇到了这么一个问题。
我的需求是 给所有人加上一个pid =1 的道具
但是有的人本身就已经有了这个道具，有的人却没有这个道具
就不能直接update 或者insert了
于是先用这个语句，每个人都 insert一个 数量为0的数据
然后 统一update
不一定事事最求最优解，稍微变通下能够解决很多烦恼。
例如：spring的corn表达式不支持last 这种语法。导致在配置时间表达式：每个月最后一天 这样的要求就达不到了。
实际上可以配置为每天执行一次，然后在业务里面判断当天是否是这个月最后一天
这种方式基本上没多大区别
类似这种办法有很多，不要脑筋转不过来就好。
mina 粘包无法解决的解决办法
- 博客分类：
- socket
如果你遇到”粘包“问题，实际上可能不是粘包问题。
使用mina的时候铺天盖地的都说要加上：ExecutorFilter
fc.addLast("executor",new ExecutorFilter(Executors.newCachedThreadPool()));
我在测试的时候发现很容易出现粘包问 ...
spring 的cache：CacheInterceptor，其作者说它是线程安全的类。
但是完全看不出怎么线程安全了。
org.springframework.cache.interceptor.CacheInterceptor
在spring aop cache的时候忘记了spel会把参数运算，引发了一个bug。
在来回检查的时候我在想：“我应不应该质疑spring cache 的问题”
但是，想来想去觉得与其质疑人家这么牛x的框架还不如多质疑下自己
顿时醒悟，发现表达式用错了："#poker.suid+#poker.buid" 导致2个表达式只向的是同一地址
遂改成"#poker.suid+#poker.buid+'b'"变成字符串，收工。
----------第二天-----
瞎了狗眼，没去看spel的文档说明
s ...
cache架构上的一些新见解
- 博客分类：
- cache
在我实践自己拓展的spring aop cache spring cache 拓展 过程中，我对如何大幅提高程序性能方面又有了些新的见解。
通过良好的设计，通过spring aop cache 确实是可以达到完全覆盖数据库操作，这样就意味着数据库操作可以被省略。
我发现这个过程中还存在一个敌人：数据库主键。
因为主键的存在，save操作必须经过数据库的返回。解决这个办法也简单：自己生成主键。
如此一来，你的数据就能简单、高效的在需要存储的时候存储到数据库中。
你需要做的仅仅是把现有的业务“不合理”的地方进行些变通。另外，你的业务最好有比较清晰分层结构。
...
freyja对分库分表设计绝对是最强大的
- 博客分类：
- Freyja2
分库、分表的设计往往比较让人头疼，据我的了解guzz、ibatis等框架在面对分库分表的时候产生了一堆奇怪的东西，通过强迫改造sql达到目的。
freyja项目的一个重要的特性就是对sql无侵入性，从第一个版本到第二个版本的sharding功能都坚持这个原则。
select * from t_user where uid = ?
如果你对guzz、ibatis等框架有所了解，你会知道当你需要对t_user表进行切分的时候他们需要你对sql进行怎么样的改造。
但是对于freyja来说，它不会去改动原有的sql、业务同样的能够实现切分功能。这就是freyj ...
坚定Freyja2的发展方向
- 博客分类：
- Freyja2
今天为了找一个错花了一个半小时，最终发现有一个小地方写错了。
虽然这个错误与Freyja没什么关系，但是我从中对Freyja做了下反省：
我在开始动工Freyja1的时候是非常有信心的，因为我觉得Freyja不是为了轮子而轮子，而是从实际应用出发解决ORM框架带来的性能上的提升，之前也说过，ORM能解析sql 能掌握数据，所以能从中改造获得性能上的提升。
对比JDBC而言，ORM才是真正地主人，JDBC只不过是数据库的傀儡。
到了Freyja2，我发现如果层次设计得足够好，完全可以在上层配合缓存把整个数据层给屏蔽掉。
这样一来完全不用去处理缓存，所以就有了对spring a ...
Mysql 批量操作重大发现
- 博客分类：
- 随便记点东西
一直测试的批量操作和普通操作性能上没什么区别。
觉得很奇怪，而且驱动里面源码也会发现表面上是批量操作实际上也是一条条执行。
后来看了http://elf8848.iteye.com/blog/770032这位的帖子
发现了rewriteBatchedStatements这个参数
加上之后，简单的测试了下效率提高了30倍
当时就让我震惊了
又测试了下1000条记录/提交
插入1.6W条记录耗时7s， 测试总耗时9s
而最开始测试无论是批量执行还是一条条支持耗时差不多都在350s
这个差距真是惊天地泣鬼神！
这个参数需要在 jdbc 5.1.1 ...
ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext
ctx.registerShutdownHook();
ctx.addApplicationListener(new ApplicationListener<ContextClosedEvent>() {
@Override
public void onApplicationEvent(ContextClosedEvent event) {
ServerTask task = ...
有没有想过：
1、你的所有数据库操作curd方法都不是线程安全的
2、你的所有业务类都不是线程安全的
3、这不是用什么线程安全集合能解决的事情
4、业务是复杂的，需要同步的变量牵扯太多东西
5、考虑同步的时候又要去注意锁的粒度，范围
之所以没把线程安全当一回事，我觉得
1、并发量不高没有感觉到危机
2、出现了并发问题，但是由于业务的一些特性这些并发问题变成了小问题而且没有被察觉到
3、没有测试
实际上上面说的终究归咎于没有测试，当然提前要有这个意识，明白业务可能会出现什么问题。
举个例子来说：你在开开心心的写业务逻辑：
//变量
//方法{
//进门
//出门 ...
freyja v2版本发布
- 博客分类：
- Freyja2
上回说了
freyja将重新把重心放在orm、sharding、cache上
1、更完善的orm
2、应用层屏蔽的底层sharding
3、应用层上的cache
那么，直接上代码了。
因为没什么开源经验，所以直接介绍freyja的思想和代码了。
1、cache部分直接改的是sprin
mysql 乱码问题
- 博客分类：
- 随便记点东西
是用cdb出现乱码问题，搞了我几个小时。
吸取的教训就是：
1、蛋疼的cdb，蛋疼的iso编码。不允许修改
2、对mysql编码的理解太少了
由于自己建的mysql数据库都是指定为utf8编码，所以自己不喜欢在url上加上useUnicode=true&characterEncoding=utf8这样的参数，命令行、工具操作数据库的时候也都很顺畅。
但是cdb的mysql使用的是默认编码：latin（iso）默认配置
本身就算是默认latin编码，只要url指定了utf8编码方式，读取操作数据也是没问题的。只要db编码方式是utf8 就像 ...
spring cache 的一大缺陷是无法对集合缓存操作
例如：信箱功能
@Cacheable(value="mailCache",key="#uid+'list'")
public List<Mail> getMails(Integer uid);
@Cacheable(value = "mailCache", key = "#id")
public Mail getMail(Integer id);
@CacheEvict(value = "mailCache ...