项籍_个人页

consumer消费速度下降会造成canal sink堵塞引发“无法”监听处理 大规模数据变更，需要考虑考虑提高下游的并发能力，提升吞吐量 针对下游能力有瓶颈时，可以引入canal+kafka的模式，基于kafka做一下中间缓存，引入更多的客户端进行并发处理来提升性能4.如果对于消息顺序有强烈需求，可以通过producter route到一个partition解决乱序问题 1.canal消费速度变慢，会造成sink卡住，引发“无法”消费 大规模数据变更，需要考虑考虑提高下游的并发能力，提升吞吐量 针对下游能力有瓶颈时，可以引入canal+kafka的模式，基于kafka做一下中间缓存，引入更多的客户端进行并发处理来提升性能4.如果对于消息顺序有要求可以考虑porducter route到一个partition解决

1.首先需要学习java基础，了解常用的语法（参考Thinking in Java）,避免下面的学习一脸懵逼2.假设你已经自学了java，对于常用的语法和技巧已经了然于心。你可以多关注一些优秀的开源产品：dubbo、spring、tomcat。任何一个优秀的开源产品都是经得起挖掘。并且可以根据自己的方向选择学习轨迹。互联网相关可以看看tomcat了解servlet原理和设计理念。2.1.举个例子，你确定看懂了java io。但是你在学习dubbo和tomcat确定能看懂这些基础是如何实践在生产，有哪些编码技巧和性能优化点需要关注的（使用篇）2.2.举个例子，你确定看懂了基础语法，但是对于dubbo、spring中的动态代理、单例、装饰器等用法是否看的明白，是否有计划去深入挖掘设计者的意图，这个时候一些设计上的技巧是可以学到的（设计篇）2.3.举个例子，你确定连spring都看懂了，但是有没有挖掘到DTD和XSD的相关细节，spring在自定义hadler时候如何有效利用XSD。import关键字和ref关键字是如何解决循环依赖问题（延展篇）3.最后你会发现，大多数生产上我们能用到的优秀产品所涉及的技能和设计理念都是千篇一律，而你需要做的仅仅是先通过书籍和博客了解大致的原理，再通过源码的学习汲取优秀的设计理念和实践经验4.最后一点很关键，需要喜欢做好总结和沉淀，东西看多了容易忘，但是能沉淀的都是方法论，是指导你后面走得更快更远的明灯，给个demo：https://my.oschina.net/tryUcatchUfinallyU/blog/266783

1.我理解预发和架构理念应该不是制约你从事java架构师的瓶颈，毕竟你已经从业10年多了2.从你的描述我看到是大数据架构师，更多的是技术架构，而非领域建设和业务架构3.所以我的理解你的困惑是java的世界里工具和类库太多，中间件层出不穷，基于自身的现状如何快速落地？所以下面的描述会重点介绍一些常用的技能如何编织成一个框架，并能复用到其他领域4.我自身做过业务架构、apm、dns等技术项目的架构和落地，举个dubbo的实例来说事：rpc框架从指令发出到response经过的那些节点。动态代理、负载均衡、协议层、网络层、服务治理、spring容器。再去对比Haproxy的负载均衡、DNS的UDP网络通信、apm的服务治理策略。Kafka的存储(pagecache)对比于Varnish、cdn厂商的存储。spring基于xsd和生命周期的拓展设计方案。5.结合第4点我锁描述的那样，Java世界里面的那些meta servcie是可以枚举的：netty、proxy、zk。任何一个优秀的开源产品都囊括了大多数6.结论是资源很多，优秀的开源产品都是你的资源，就看你愿意钻研多深了

假设你已经自学了java，对于常用的语法和技巧已经了然于心。你可以多关注一些优秀的开源产品：dubbo、spring、tomcat。任何一个优秀的开源产品都是经得起挖掘。举个例子，你确定看懂了java io。但是你在学习dubbo和tomcat确定能看懂这些基础是如何实践在生产，有哪些编码技巧和性能优化点需要关注的（使用篇）举个例子，你确定看懂了基础语法，但是对于dubbo、spring中的动态代理、单例、装饰器等用法是否看的明白，是否有计划去深入挖掘设计者的意图，这个时候一些设计上的技巧是可以学到的（设计篇）举个例子，你确定连spring都看懂了，但是有没有挖掘到DTD和XSD的相关细节，spring在自定义hadler时候如何有效利用XSD。import关键字和ref关键字是如何解决循环依赖问题（延展篇）最后你会发现，大多数生产上我们能用到的优秀产品所涉及的技能和设计理念都是千篇一律，而你需要做的仅仅是先通过书籍和博客了解大致的原理，再通过源码的学习汲取优秀的设计理念和实践经验js我的学习参考了锋利的JQ，个人感觉书籍并不是重要的，方式方法最重要GIS这块暂时没有涉猎，无法给你比较好的建议

1.找个比较干净的spring版本，比如2.5.62.搞明白spring的大致原理（IOC），避免源码阅读不知所云，毫无条理，核心是要了解ioc的大致架构，核心服务和常用的扩展点3.BeanFactory的new方法入手了解容器是如何初始化（资源加载策略、校验策略、注册机制），同时也会了解到如何通过平台化的方式支持自定义的bean（handle、namespace）4.BeanFactory的get方法入手去了解如何去生产和托管对象（装配机制、生产机制、作用域机制:scope的面纱），同时你会发现原理上看到的那些扩展点BeanPostProcessor、InitializingBean的使用场景和使用意图，获取源码里面还发现了不为人知的秘密: nestedBw5.了解了整个Bean的生产机制，也明白了若干拓展点的使用场景和意图，那么FactoryBean可以用来干嘛，AOP的编织入口在哪里，也就一目了然了6.可以参考：https://my.oschina.net/tryUcatchUfinallyU?tab=newest&catalogId=300810（之前自己学习轨迹）

1.找个比较干净的spring版本，比如2.5.62.搞明白spring的大致原理（IOC），避免源码阅读不知所云，毫无条理，核心是要了解ioc的大致架构，核心服务和常用的扩展点3.BeanFactory的new方法入手了解容器是如何初始化（资源加载策略、校验策略、注册机制），同时也会了解到如何通过平台化的方式支持自定义的bean（handle、namespace）4.BeanFactory的get方法入手去了解如何去生产和托管对象（装配机制、生产机制、作用域机制:scope的面纱），同时你会发现原理上看到的那些扩展点BeanPostProcessor、InitializingBean的使用场景和使用意图，获取源码里面还发现了不为人知的秘密: nestedBw5.了解了整个Bean的生产机制，也明白了若干拓展点的使用场景和意图，那么FactoryBean可以用来干嘛，AOP的编织入口在哪里，也就一目了然了6.可以参考：https://my.oschina.net/tryUcatchUfinallyU?tab=newest&catalogId=300810（之前自己学习轨迹）

你的问题要分开来看，线程数多了性能反而差和如何解决高并发问题两个问题 线程数多了性能反而差 1.伴随线程数的加剧，cpu和内存的开销也会伴随着增长，最直观的体现的sys增长，分配给业务线程使用的cpu时钟相应会降低；其次线程分配的内存开销无疑家居了GC的开销，对吞吐的影响也是不低2.如果VM和JVM并没有到瓶颈，这个时候需要考虑是否受限于锁和IO。举个例子logger同步锁和依赖的外部IO瓶颈 解决高并发问题 关于这个问题需要视情况而定了1.如果是CPU密集型应用，IO并非瓶颈，可以考虑通过充分使用cpu核数来提高并行度，一般配置cpu core线程即可2.如果是IO密集型应用，应用的瓶颈集中在外部IO，在外部IO负载范围内可以通过增加线程数的方式解决吞吐问题3.如果计算任务涉及到锁竞争，可以考虑降低锁的粒度或者取消锁，举个例子ringbuffer4.基于之上的场景如果需要继续提高并发度，可以考虑做一些热点优化，举个例子热点缓存优化，热点缓存本地优化（不过这个时候就需要考虑本地缓存的大小和失效时间，过长会导致老年代增长过快，触发FGC，这个时候反而得不偿失，经验值一般是20s之内）5.有的时候也可以考虑用空间换时间，在一些数据封板的场景可以考虑预计算&缓存代替实时计算提高并发度6.有的时候需要对业务逻辑进行裁剪，针对于不同场景进行计算流程的自定义，裁剪掉不必要的开销7.一些中间件、jvm和os的优化就不在这个话题里描述了

同一个Tomcat多个实例原理篇：多个war部署一个tomcat实例的本质是容器中维护多个WebModule（关注下应用中的web.xml）,通过request mapping到相应的Module进行请求的处理。从业务来看共享的资源包括了Endpoint(流量)、HttpServletRequestBuffer(缓存)、RequestMapping、HttpServeltRequestParser(计算);不共享的资源包括了ServletRequestContext、 Session、Servlet容器篇：共享了JVM那么不得不说说内存管理和GC可能遇到的那些事。你设想A应用热部署了应用导致老年代晋升触发了FGC，B应用发生了5S的服务不可用；再设想A应用用户上传一个大文件造成了OOM，B应用也跟着宕机了部署篇：如果是不同实例，那么部署在一个tomcat就会面临上述问题；同一个实例部署在一起就更没有必要了（同样的JVM环境下应用的内存环境都是double，无疑加剧了GC的压力）同一个服务器多个Tomcat实例资源隔离问题：JIT和GC对CPU的抢占会影响其他实例中服务的稳定性资源共享问题：磁盘综合来说，多实例部署一个Tomcat不推荐；一个服务器多个Tomcat在服务稳定性不是特别严苛的场景下是可以接受

CPU飙高一般的原因是JIT、FGC或者走到死循环的代码逻辑中502的错误码一般都是后端服务无响应常见的做法一般是先jstcak线程，随后通过top -H 获取java进程占用cpu最多的线程号，然后匹配问题线程即可定义最耗时的那段逻辑但是部分场景是老不及jstack现场就丢失了，这个时候可以通过agent探针定期采集发现问题，或者通过线程池满的事件去触发jstack（借助中间件）如果还是发现不了问题可以再看看是否触发了JIT，从code cache的涨幅或者开启jvm启动参数记录JIT详情去定位

从你描述想做的系统来看，如果是allinwar的话，业务逻辑采纳的Java框架建议选择熟悉、开源社区比较活跃的框架，类似于SpringMVC如果你的应用还期望做一些域治理的的工作的话，从描述来看包括了三个系统：1、交易系统（在线系统，关注交易系统和业务的稳定性）；2、汇总统计（在线系统，关注单据的功能：类似于订单管理）；3、结算系统（离线系统，关注清结算和对账业务）按照上面描述的域拆分，选型也是有区分。对于离线系统可以选型熟悉的Spring容器；在线系统如果不想做服务化治理的话可以选型servlet容器+SpringMVC;

主要涉及的知识点JVMTIJNIClassLoaderInstrumentJConsole(或类似产品)Javassist(或ASM等字节码类库)针对于不同Web容器或者中间件如何植入javaagent探针加载的jar包由SystemClassloader加载，通过classfile transform入口变更字节码而我们往往通过插桩的方式埋探针，执行流程通过桩代码路由到APM的核心逻辑但是这里面有个问题在于桩代码的执行过程中如何访问宿主中的类和方法（类似于HttpservletRequst）对于普通的web容器只需要定义桩ClassLoader的加载逻辑即可；但是对于osgi容器就无法识别(这一点优雅的方法都是有损的，不做具体描述了)因此主要影响的是classloader，对于宿主jvm是web还是中间件并不重要