今天被一个架构师面了

1. 上来就问读过什么框架源码
   说实话，没读过什么框架源码，这个以后要研究下了
2. 用过什么设计模式
   我说了十来个
3. Redis有哪些数据类型
   这个问的有点小二科了
4. 设计一个连接池
   估计是问你设计能力
5. 分布式事务更好的解决方案是什么
   两阶段提交中的第二阶段, 协调者需要等待所有参与者发出yes请求，或者一个参与者发出no请求后，才能执行提交或者中断操作。这会造成长时间同时锁住多个资源，造成性能瓶颈，如果参与者有一个耗时长的操作，性能损耗会更明显。
   实现复杂，不利于系统的扩展，不推荐。
   TCC (Try-Confirm-Cancle)

TCC，是基于补偿型事务的AP系统的一种实现，具有最终一致性。

对比与前面提到的两阶段提交法, 有两大优势：

TCC能够对分布式事务中的各个资源进行分别锁定，分别提交与释放，例如，假设有AB两个操作，假设A操作耗时短，那么A就能较快的完成自身的try-confirm-cancel流程，释放资源，无需等待B操作。如果事后出现问题, 追加执行补偿性事务即可。
TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作)，也就是各服务之间可以在一定程度上”异步并行”执行。
适用场景

严格一致性
执行时间短
实时性要求高
举例：红包、收付款业务。

异步确保型

通过将一系列同步的事务操作变为基于消息执行的异步操作， 避免了分布式事务中的同步阻塞操作的影响。

需要额外说明的一点，就是事务消息投递到MQ订阅方后，并不一定能够成功执行。需要MQ订阅方主动给予消费反馈（ack）：

如果MQ订阅方执行远程事务成功，则给予消费成功的ack，那么MQ Server可以安全将事务消息移除；
如果执行失败，MQ Server需要对消息重新投递，直至消费成功。
注意事项

消息中间件在系统中扮演一个重要的角色，所有的事务消息都需要通过它来传达，所以消息中间件也需要支持 HAC 来确保事务消息不丢失。
根据业务逻辑的具体实现不同，还可能需要对消息中间件增加消息不重复，不乱序等其它要求。
适用场景

执行周期较长
实时性要求不高
例如：

跨行转账/汇款业务(两个服务分别在不同的银行中)
退货/退款业务
财务，账单统计业务(先发送到消息中间件, 然后进行批量记账)
最大努力通知型

这是分布式事务中要求最低的一种，也可以通过消息中间件实现，与前面异步确保型操作不同的一点是，在消息由MQ Server投递到消费者之后，允许在达到最大重试次数之后正常结束事务。

适用场景

交易结果消息的通知等。

出处：http://blog.csdn.net/hxpjava1/article/details/77841791

微信扫描关注JAVA架构公众号噢，阿里大牛分享知识。
1、具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加群。

2、在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加群。

3、如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的，可以加群。

4、觉得自己很牛B，一般需求都能搞定。但是所学的知识点没有系统化，很难在技术领域继续突破的可以加群。

1. 群号：高级架构群 647631030备注好信息！

6.阿里Java高级大牛直播讲解知识点，分享知识，上面五大专题都是各位老师多年工作经验的梳理和总结，带着大家全面、科学地建立自己的技术体系和技术认知！