三个月的回顾 --记于9.5日

来到阿里巴巴菜鸟网络学到了很多。了解了开发的一整套流程，感受到前期UC、TC评审的激烈讨论、开发过程中分工配合的欢乐、提测中的心惊胆战、发布上线的振奋、激动。有过程就有收获、记录下其中技术上的收获。
一、webx框架、ibatis框架。
之前在学校的时候主要使用Spring、hibernate、Struts框架。而webx框架是把spring框架做的更好，增加了比如页面渲染等功能，这样是为了实现团队之间的更好的协作吧【写更少的代码，规范性错误出现的可能性也就越少】。但是这样封装也会出现问题：想自己在后台写一个页面自动跳转逻辑都很难实现。
ibatis框架相对于hibernate而言，需要开发人员自己自己编写大量sql，而hibernate可以直接做到O/R映射。但是ibatis这样有坏处也有好处，坏处是写了大量代码，好处是灵活性、可控性较高。说到这里，不得不说之前参与过的某项目的时候遇到的ibatis的问题。数据库中一个数据类型为Long的weight字段，如果之前存值了，那么之后就不可以再更新为null了，因为ibatis中的sql写法是isNotNull,
遇到为空，直接忽略。而isNotEmpty更是判断字符串为空字符串也要跳过。

二、分库分表利器：TDDL
mysql数据库单表存数据量最好不超过5个G。阿里业务系统数据庞大，分布式数据库必然趋势。作为分库分表的中间件TDDL就出现了。
Tddl是主要部署在ibatis和其他orm框架之下、JDBC DRiver之上，整个中间件实现了JDBC规范。 
连接池管理、

使用sequence实现全表去重、

访问均衡策略、

TDDL支持JDBC事物、支持跨库，但是却不能支持跨库+事物。所以在决定分表字段的时候，需要慎重考虑啊！！

三、HSF的魔法：远程服务？本地服务？ 
系统越做越大，大系统划分为小系统；新增业务，调用现有端口服务。这些都会导致一个问题，不同系统间接口服务如何进行调用。服务框架HSF登场，神迹般把远程服务变成了我们眼中的本地服务。
HSF是一个RPC框架。通过一个taobao-hsf.sar的包实现，放置在阿里中间件 集中营Pandora容器中。Pandora容器可以实现隔离化、模块化。通过java类加载的双亲委托机制，实现了HSF使用Pandora容器内部定义的sar包版本，使用web容器中定义的spring等的jar包版本。

一系列的负载均衡的措施实现了HSF的高效性：归组设置、路由设置、权重规则、同机房优先规则、一致性hash选址，而这些个人感觉是hsf提供给使用者的最大的好处——不需要关注太多底层，在配置文件中给我更多的灵活性选择。

在某系统上的注册和消费机制，保证了日常、预发、线上的服务隔离。

高性能异步调用，通过Future调用、回调等方式来实现。

网络传输需要序列化，我们使用的大部分都已经是某中间件2.0以上的版本，那么我们主要的序列化方式是hassien2.需要DTO实现Serializable

与notify区别，两个都可以实现异步的远程通信，但是notify支持事物，hsf不支持事物。但是hsf可以借助notify实现可靠的服务调用【这个还没有理解，需要进一步学习】

四、Notify：notify me,but don't wait !!
最早理解notify的时候，是在一个场景下。淘宝用户下单、发送银行扣款通知给notify，notify直接返回给用户success。之后notify负责把该扣款的动作给完成掉。其中减少了用户等待的时间成本。所以开头写下了：notify me，but don't wait!

notify系统发送消息两段式提交。
notify发送消息有可靠性、重复性、无序性。 无序性是需要服务器【订阅者】在接收消息的时候做一个根据消息的时间戳的幂等操作。
notify的分布式事物保证。
客户端和服务器都可以是一个集群，通过在configServer上进行注册。
异步调用 IO保证高效性.

加入一段新的总结：

五、metaq

回溯消费、广播消费、集群消费、亿级消息堆积、分布式事物、定时消息、消息重试。

消息重试的服务器代价很高的。对于消息量大，并且失败率很高的应用，就不要使用metaq了。

通过使用队列的形式、保证消息的顺序性。

队列都是持久化到磁盘队列。对IO性能要求很高：
message全部写入到一个独立的队列，完全的顺序写；message在文件的位置信息写入到另外的文件，这样就可以保证数据的可靠性，又能支持更多的数据队列。

发送消息、订阅消息当然少不了负载均衡策略。

异步复制。不管producer还是consumer都是无状态节点，可以实现主备分离。而异步复制就是slave启动一个线程，不断从Master拉取数据。整个实现过程其实和mysql的主从同步是类似的。

与notify的对比：
1、notify在分布式事物上做的更好。其实两个都支持分布式事物
2、metaq通过队列。保证了消息的顺序性。notify不能保证消息的有序性。
3、实时性上，notify较好，收到数据后可以立即发送给客户端。而metaq就要看多长时间pull一次了，大概也是几毫秒的延时。

总的来讲：notify事物做的好，在交易系统等对事物要求较高的系统中使用。metaq在消息顺序性、回溯上有优势，那么适合高吞吐量的系统。数据库同步、实时计算等场景使用。其实对于我们现有的村淘系统，对于notify和metaq的没有什么使用差别要求的。

总结了一下，突然发现不少自己没有关注的点，比如：hassien2序列化、hsf如何可以通过notify来实现可靠的调用、深入看一下回调机制等等等等

还有一些其他的理解，不在一次全部写完。不过会在这几天内总结出来。以后也会补全完善已经写出来的，不断加入自己新的理解。