对于做java web开的多数程序员会选择SSH、Spring Mvc 、SSI之类的框架！这些框架的优点我想大家都很清楚，在这里我就不多说了！
当你遇到下面的需求的，而且要达到快速开发的时候，你会发现用这些框架组合好像不太现实！而且会成为一种累赘.
本人以前做是做C++、.net 的开发，2011年8月 转入java项目组，负责一个产品开发，主要任务是负责这个产品的程序框架！
目前这个框架基本上以成型，在这里我主要想和大家分享一下java开发、框架设计、以及产品设计之路的经验，不足之处希望大侠指点一下，
在用做这个框架之前，我对java主要了解还只有J2SE、jsp，servlet，JDBC！
2011年8月公司决定把以前引以为豪用delphi开发一个产品做成web形式，
（据说是老板在一次项目投标中被打击了，一个客户对他说了一句这样的话：“这个年代ERP还有用C/S的，还好意思来投标，太out了吧”）
于是公司开始筹划这个web形式的产品开发，开始打算用.net 开发，没过几天产品经理的在一次同学聚会中听他同学说.net 成本高，不能跨平台！
对于我这种做了多年.net开发人来说还是希望公司用.net的，不过mono跨平台成功的商业项目还不多，所以我没有足够的理由说服产品经理，
于是老板决定用java开发，开始找java项目负责人，应该薪水的原因，公司没有招聘到合适的项目负责人，于是我就成了这个产品开发的技术负责人，
应该是第一次做java项目组负责人时鸭梨山大，于是就开始研究java的各种框架，Strut，jsf，hibernate，iBATIS，Spring 了解流行框架所拥有的优缺点，以及所能做的功能，
两个星期之后需求和设计总结下来了，因为这个产品以前是c/s delphi开发的，现在改成java web方式
所以需求总结进行的比较快，产品的需求通过产品经理审核就开始动工了！
因为产品要求灵活，而且业务比较复杂的！这个产品涉及比较广。
数据库有一千多个表（实体），两千多个视图，两百多个表量函数和普通函数，以及一千多个存储过程
涉及：原材（进销存管理）、设备、生产调度，产品检测、人事（CRM）、财务，预算、等管理！
产品要求达到的基本功能
第一、产品要满足行业内大小公司、集团客户的的需求
第二、产品要为非程序员提供第二次开发接口，（用户在数据库添加几个表，可以自定义生产维护页面、和查询业务）
第三、每个用户都有个性化数据，每个用户看到的页面、字段不一样，可以主题风格！
第四、每个用户有不同的功能模块权限，以及不同的数据查询条件，可以用管理员定义查询过滤，
第五、页面布局自定义改动，（用户可以改变控件的位置，可以添加或者删除）
第六，下来框的数据，用户可以动态的改动、动态级联关系用户可以自定义设置
第七、用户对每个字段可以指定验证规则（比如有写用户可以录入重复的数据，二其他的用户不能录重复的数据，指定有些用户必填有些用户可以为空）
第八、数据添加、修改、删除、日志记录, 系统异常记录
权限设计
权限分角色、角色组，部门权限，个人权限，功能模块权限，菜单权限，查询条件权限，操作权限、字段（增删改查权限）
流程设计
生产流程、工作流程、审批流程
报表
要求、可以在线编辑打印报表，图形化报表、导出excel，pdf，在线打印速度必须快，一秒钟要可以打印一张！
框架要求统一规范，
代码统一规范、命名统一规范！格式统一规范，
类设计必须到底可以扩展，可以维护，要实现多数据库、业务逻辑层的代码可以替换方便以后维护和升级、跨平台，多国语言，
在设计上尽量可以达到兼容多种开发语言模式！（比如方便以后用 .net 重写）
公司要求，我两个月的时候把框架设计出来！公司再招聘七八个一年多工作经验的java程序员，然后一年之后上线！
这样的需求对于没有java开发的我欲哭无泪 ，于是找做java开发同学、朋友要他们开发的项目源码。我想最后的结果大家应该知道的！
下一篇讲框架的基本设计！
设计之路、如何应对灵活变动的需求，以及能够快速开发
分布式系统缓存设计浅析
前几天听了部门内朋春大牛讲分布式缓存的一个技术分享，还是非常有收获。
PPT如下：
这个分享的副标题是“简单的事情从来不简单”，这句话讲得非常在理。缓存看似简单，但要做“好”一个缓存系统也是很有讲究的。
写点自己的心得收获吧：
1. 分布式缓存面临比较大的三个问题：
（1） 数据一致性。
在分布式系统这点显得尤为重要，主要原因有三点：
缓存系统与底层数据的一致性。这点在底层系统是“可读可写”时，写得尤为重要
有继承关系的缓存之间的一致性。为了尽量提高缓存命中率，缓存也是分层：全局缓存，二级缓存。他们是存在继承关系的。全局缓存可以有二级缓存来组成。
多个缓存副本之间的一致性。为了保证系统的高可用性，缓存系统背后往往会接两套存储系统（如memcache，redis等），以上的ppt也主要是讲这方面的内容。
（2）缓存雪崩
当缓存系统重启或者所有缓存在同一时刻失效（比如某些系统为了提高速度，会在系统启动是统一将大部分数据刷到缓存中，此时如果设置缓存时间都是24小时，那24小时过后，那就悲剧）时，应用系统由于扛不住压力而直接挂掉。
（3）缓存穿透
查询一个必然不存在的数据，查询一个必然不存在的key，每次都会访问DB，如果有人恶意破坏，那么很可能直接对DB造成影响。
第一点偏重数据的真实性和实时性，而第二点和第三点更多从性能上考虑。同时缓存并不一定是必需的，特别是当写操作特别频繁时。
2. 缓存数据的淘汰
原先缓存数据的淘汰往往是用设置缓存时间，比如我设置某个数据的缓存时间是24小时，之后的24内这个缓存是不会失效的。优点当然是简单，缺点也很明显就是不都灵活，没做到好的精细化管理。
我们能利用的资源就是：1. 给缓存加tag，2. 版本号（必须单调递增，时间戳是最好的选择）3. 提供手动清理缓存的接口。
相关步骤可以参见以上的PPT内容。
缓存相关接口：
var me = Cache.create(...); me.set(key, value, ttl, tags); me.get(key); me.tagrm(tag, offset, flush);
缓存的数据结构如下：
var data = { ‘i’:now, /** 数据写入时间戳 */ ‘e’:now + ttl,/** 预期过期时间 */ ‘k’:key, /** 原始key */ ‘v’:value, /** 原始值 */ ‘t’:tags /** tag列表 */ };
我刚开始的也没弄明白为什么在data中还要存“原始的key”，后来经朋春提醒，才弄明白：原始的key可能过长或者存在特殊字符时，是不能直接作为某些系统的key，因此往往会对原始key做一次hash来作为缓存的新key。
3. 缓存淘汰的策略
缓存淘汰的策略有两种：
(1) 定时去清理过期的缓存。
（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂，具体用哪种方案，大家可以根据自己的应用场景来权衡。