如果使用的是默认的<aop:aspectj-autoproxy/>，当target有interface时，生成proxy会实现这个interface，但这个proxy并不是target的子类。 有时候，你的target有interface, 但仍然有自己的public方法需要暴露，这时你应该保证你的aop proxy会继承target. 办法就是： 引用 <aop:aspectj-autoproxy proxy-target-class="true"/>
public static MyEnum safelyParse(String str) { if (str == null) { return null; } MyEnum[] values = MyEnum.values(); for (MyEnum value : values) { if (value.name().equals(str)) { return value; } } return null; }
分库可以将数据库访问的压力分担到多个子库中，提升数据库读写的性能；但数据库一旦分库，上层的读写操作就必须考虑分库这一事实。比如说，要查询某条记录，查询条件除了业务上的条件，还应该把带上一个分库的键值对，好让你的分库框架找到这条记录所在的库。 我根据自己的项目经验稍微归纳一下。 核心准则：尽量让所有的访问都只落在一个分库里。如果要访问多个分库才能完成操作，那么访问性能会由于多次网络I/O而下降，在事务方面也很不方便。 推论 1. 所有的SQL都应该带上分库的键值对，以帮助系统路由到记录所在的分库。比如，你的论坛系统中的帖子是按版面ID分库的，那么在查询某个帖子的详情时也应该把这个贴子所在版面的ID放到SQL里。 2. 被分库表的子表如果需要分库的话，应该按同一维度分库，以保证某主记录的相关子记录跟它总是落在同一个分库中，以方便表连接和事务。 如果帖子是按版面ID分库的，那么一个版面下的所有帖子“赞”记录也都应该跟这个版面下的所有帖子放在同一个分库中； 否则你很难实现“找出某版面下前十个帖子及每个帖子前十个赞贴的人”和“在同一个事务中新增一条评论记录并且将帖子的评论数加1” 3. 存在表连接和事务的其他场合，也都应该尽量保证相关记录出现在同一个分库。 4. 分库数最好不要特别多，以节省万一要全库扫描时产生的成本。在某些情况下，你的查询可能就是要扫描所有分库，一次分库查询就是一次网络I/O，但如果查询次数不多，这样的性能往往也可以接受。所以如无必要，不要设置过高的分库数；可以通过“清理三个月前数据”等机制以控制全库的总记录数，这样一来所需的分库数也不太多。
怎么从 List<Person> personList中取出 List<Long> idList ? 没有闭包语法的情况下，你只能写一个for循环，一个一个往里塞。。。 老写这种东西，会不胜期烦。 可以写个微型的框架，让你写更少更简洁的代码完成这种事情。 你会这样用： List<Long> idList = MyCollectionUtils.extractProperty( personList, GetPersonIdPropCommand()); public static final class GetPersonIdPropCommand implements GetPropertyCommand<Person, Long> { …… } 框架在这里： /** * 从一个类集中抽取中每个元素的某个属性. 举例说明：{person1, person2} => {person1Id, person2Id} * * * @param objects * @param getPropCommand * @return */ public static <O, P> ArrayList<P> extractProperty(Collection<O> objects, GetPropertyCommand<O, …
由于并发、程序bug或其他原因，你的统计值或多或少可能不那么准确。 如果说不准确可以勉强接受，超住值域之外就属于丢脸了。 如果你的页面上显示一个人发过的帖子数为-1 , 那就贻笑大方了。如果是0。即使不精确，也还说的过去。 所以，在持久化任何统计值之前，先把这个值正规化为值域的边界值(比如，小于0则置成0)。
社区系统里的各种标签、徽章应该由谁创建，由谁来贴标签、颁发徽章？ 贴标签、颁发徽章当然要由运营操作人员来做。 谁来创建呢？如果这个标签仅仅用来显示，而不会扭曲任何if/else逻辑，那可以由操作人员在后台界面上完成。 否则，就应该由开发人员创建，因为代码里要用它。如果还没创建好，怎么用它？ 一般情况下，可以仅仅作为枚举类写死在代码里，连数据库表都不用建。
冗余本应计算出来的数值 统计数值可以通过select count(*)临时计算出来，但这种计算可能比较耗时，所以可以直接在表中增加这样一个字段并在相应事件发生时更新。 比如一个贴子的赞数、评论数都可以直接作为帖子表的字段，新增赞、评论时再累进这些字段。在查询一批贴子时，可以不用任何附加SQL就可以拿到这批帖子的赞数和评论数。 还有个例子：“前十个赞本贴的人”，也可以拼成单条字符串放在帖子表中。 字段冗余 A表除了外键关联B表的主键，还冗余了B表的其他一些字段。 1. 这种策略一般用于避免表连接： 在很多场景下，只需要查询A表即可。 2. 约束：业务上规定被冗余的字段不会发生改变，否则，修改B表后还要把A表也改一下，代码中很容易遗漏这一点，这样做还会带来性能损失。 3. 不冗余，不代表一定要表连接。要冗余还是不冗余，可以参考这里。 整条记录冗余 A表和B表没有外键关系，而是“复制”关系。它们字段基本上一样，或者说一个是另一个的子集。 分库分表环境下常常需要这种策略，以便对单张表按多个维度进行拆分。 SNS中有个典型的例子： 关注关系。 我们既要查看一个人的偶像列表，又要查看一个人的粉丝列表。所以，当数据量大时，你既要按粉丝ID分库，又要按偶像ID分库。一个关系有两个分库维度，那就只好做两张表了。 最好用一些专门的数据复制中间件完成这种事情。这类复制逻辑非常简单，中间件一般能轻松支持； 使用中间件，也可以使这种冗余关系对上层透明，业务逻辑编写者不需要自己实现数据复制。
在web2.0系统中，用户的一次写操作，可能不仅仅意味着系统里要新增一条相应的记录，系统里可能还有很多统计性的事情要做。 比如在社区系统中，一个用户发了一个帖子，系统除了生成这个帖子的记录之外，还要给用户的发贴数加1，用户使用过的tag数加1，每个tag对应的帖子数加1 。。。 可以把主流程（生成帖子记录）和附加流程（各种加1）整合在一个事务里执行，程序健壮且易理解。但也可以在完成主流程后，发一条消息出去，让消息的消费者完成这些统计操作。 这种 异步机制最明显的好处，就像很多人说的那样，可以 尽快响应用户请求，提升性能。 但更重要的好处是， 它实现了解耦，有利于各模块独立发展，并促进分工。 1. 把附加流程实现在主流程的模块里，不符合主模块的职责定位； 主模块可能要因此依赖很多附加模块的库，不利于系统的简洁，对发布也有影响。 2. 把附加流程实现在主流程的模块里，不利于主模块和附加模块的开发人员各司其责，代码也容易遗漏或出错。 由于异步消息的不可靠性，这样做也有它的副作用： 1. 消息可能会丢失，导致附加流程未能执行。 要解决这个问题，只有使用不丢消息的消息中间件：这个中间件只有在收到消费者的回执后才会删除消息。 2. 消息可能重复，导致附加流程执行两次。如果你的附加流程不是统计性质，则让消费者做好幂等性就好了； 如果是统计类操作的话，那就要另建去重措施了。如果对统计数值的准确性要求不高，可以用bloom filter简单搞定； 否则的话，需要在缓存里保存一段时间内的消息ID，收到消息后做下比对再决定要不要消费它。
你的记录一般会按某个业务字段排序，比如ID，生成时间等等。 在论坛或SNS系统中，你可能要允许手工调整记录间的排序，比如“置顶一个帖子”，“下沉某个帖子让人感觉它是一个月前发表的”等等。 在设计社区系统的数据库时，你首先要有意识地考虑下某个记录列表是否需要手工排序。如果需要，你应该使用一个专门的字段来解决这个问题。 ============================= 下面就说下这个字段（假设它叫 sort_order）相关的设计与实现： 1. 考虑到比较式分页的需求，这个字段的值要像ID一样不能重复。你可以用数据库的序列生成器生成这个字段，也可以像下面将要说的那样，根据一定的编码规则生成这个字段。 2. 如果你设计的是社区系统，那么你的记录的原始排序规则很有可能是“发表时间”；这时“手动干预排序”可能相当于“让人感觉某个帖子是另一个时间点发表的”。 因此，sort_order最好体现时间信息。我的做法是：sort_order = 记录创建时间的毫秒数 串接 3位随机数。 这样基本可以保证唯一，而且携带时间信息。你会问为什么不直接用纳秒数？因为系统生成纳秒数需要1毫秒以上的时延，对性能伤害很大。
如果你的系统既有web界面，又要暴露remote api，应该怎么分层？ 我的回答是： 1. 如果web操作为主，remote api是少数，那就用最常见的web-biz模式；web层不必那么薄，可以通过组装biz services实现use cases 2. 如果remote api为主，web操作为辅，则应该用web-app-biz模式，并且web层不准直调biz层。 ============================================== 这张图好理解，也比较容易接受：app层组装biz service并实现校验逻辑，对外暴露服务；web层本身很薄，主要职能是把请求转给app层，校验都不用做。 可能存在的争论是：为什么要禁止web层直调biz层？ 两层在同一个系统里（比如同一个JVM里），直调无障碍； 禁止直调的话，如果一个操作不作为remote api对外暴露，仍要在app层中加一层封装的代码供web层调用，岂不是很蛋疼？ 这些坏处确实是存在的。但是经验表明，禁止直调带来的好处更多： 1. 系统做大后，出于分工或性能考虑，可能需要把web层剥离为一个独立系统。 如果你禁止直调，分分钟可以完成剥离； 否则，几乎不可能，除非你直接把biz service暴露成remote api（非常不好的做法）。 2. web层直调省不了多少工作量。问自己这样一个问题：校验及报错在哪里做？ 非直调的话，校验做在app层，并使用标准的errorCode/errorMessage API返回错误，web层自己不必再校验； 直调的话，web层需要自己做一堆校验，工作量还是有的。 3. 直调时，web层要自己实现校验逻辑和biz service组装逻辑，直接使用domain objects, 这要求web层的开发者也要非常非常清楚业务逻辑；如果不允许直调，web层开发者只须组装request对象和渲染response对象，他可以把精力更多地放在javascript/css上，对业务逻辑只需有所了解即可；也就是说，web层的开发可以轻松外包（对于资源紧张的团队，这一点很有意义） 4. 最严重的问题在于，如果允许直调，对于某些use case，web层和app层可能会实现重复的校验逻辑和biz service组装逻辑。不要小看这些逻辑，可轻可重； 如果没有实现在单一的地方，系统很容易腐化 （违反DRY原则) ========================================== 禁止直调除了要作为开发规范让大家遵守，也应该在技术上作好防卫性设计。如果你用的是maven，可以这样： <!–web工程的pom.xml–> <dependency> <groupId>some.group</groupId> <artifactId>app</artifactId> </dependency> <dependency> <groupId>some.group</groupId> <artifactId>app-impl</artifactId> <exclusions> <exclusion> <groupId>some.group</groupId> <artifactId>biz</artifactId> …