慕之_个人页

可以使用Spring 的事务管理器， 在你要控制事务的方法上加上@Transaction注解即可， 不用自己控制事务的开始，提交和回滚。

nginx转发到哪儿？ 是不是下游处理具体业务逻辑的地方报的404， 正常情况下nginx作为负载均衡器，支持上万的并发是没问题的。

补充一点， 高并发场景上要考虑是使用内存还是缓存， 建议是使用缓存memcache或者redis都行， 防止并发量过高导致内存爆掉。

基于楼主的问题， 实现高并发， 可以从两个角度来考虑。第一个角度是优化接口逻辑， 降低接口响应时间。 可以借助一些工具分析每一步的耗时， 这样就知道哪块可以优化。 通常的做法是使用缓存来挡流量。第二个角度就是扩容机器， 具体扩容多少机器可参考单台机器最大支持的并发量。接口优化了，机器也扩容了， 后面需要做的就是按照既定的目标对系统进行压测， 压测不光是看自身系统能不能支持这么高的qps， 还要看底层的db, 下游的接口是否能支持。如果db不支持， 可考虑进行主从分离， 分库分表； 如果下游接口不支持需要给下游接口沟通让其扩容。

Spring 的bean的scope设置成prototype， 就是每次都要创建一个实例， 可以看一下Spring的源码， 创建一个Spring实例是很复杂的一个过程， CGlib代理只是其中的一步，底层也是通过反射完成的， 我觉得耗时的关键不在 CGlib代理， 而是在整个Spring加载和实例化bean的过程。 通常情况下使用Spring来管理bean都是将scope设置成singleton， 这样bean实例就是一个单例， 不用每次getBean时都实例化一遍。 具体能不能用singleton要看你的实际应用场景了。

这个问题首先涉及到工程中代码结构的问题，正常来说会分成以下四层， 从低向上依次是：dao层： 存放的是对底层数据库的操作service层： 对底层的封装， 比如对dao层的封装， 对外围接口的封装等biz层： 即业务层， 该层存放的是业务逻辑类controller层： 及入口层， 该层负责对请求参数进行校验， 调用biz层处理业务逻辑， 然后对结果进行组装。弄清楚了代码结构后再说一下异常处理原则： 能处理就早处理基于楼主的例子， db异常应该是在service层被spring aop事务管理器捕获了， 即就是说@Transactional应该放在service层的方法上。另外， 一旦回滚事务管理器还会抛出数据库回滚异常， 接着biz层就要捕获这个异常来判定db操作是否成功，进而执行不同的逻辑处理。

先说一下AOP是干什么呢， AOP是面向切面的编程， 通过AOP可以将业务的各个部分进行隔离，从而是各个部分耦合度降低。常用于做日志记录，性能统计，安全控制，事务处理，异常处理等。 接着再介绍几个概念：Joint point：表示在程序中明确定义的点，典型的包括方法调用，对类成员的访问以及异常处理程序块的执行等等，它自身还可以嵌套其它 joint point。Pointcut：表示一组 joint point，这些 joint point 或是通过逻辑关系组合起来，或是通过通配、正则表达式等方式集中起来，它定义了相应的 Advice 将要发生的地方。Advice：Advice 定义了在 pointcut 里面定义的程序点具体要做的操作，它通过 before、after 和 around 来区别是在每个 joint point 之前、之后还是代替执行的代码Advisor： 通知器， 包括通知和切点 结合上面的概念再来看楼主的例子就比较清晰了 定义了切点， 即要拦截哪些操作。 这个例子就是说要拦截com.ace.service.impl这个包下的所有以Impl结尾的所有public方法。 定义了通知器， 该通知器指定了刚刚说的那个切点， 还指定了基于这个切点要做什么操作， 具体的操作逻辑在txAdvice中。

设置多大要看应用的具体情况而定， 你出现的PermGen Space OutOfMemory说明了是永久代内存溢出了， 这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入， 可能是你的应用会加载了很多CLASS导致的， 稳定确定了要解决的话只需要调整永久代区域的大小， 方法如你上面所说将PermSize和MaxPermSize调大些。

Tomcat的连接数和jvm参数要根据机器的硬件指标以及要部署的应用的的情况调整的， 不存在一种普世的方式。 针对一般的应用可按照一楼给出的配置， 如果对性能要求很高的应用， 需要通过分析测试来调整对应的参数，以让机器能达到高利用率。

通用的概念： Dubbo 是一个分布式服务框架，提供了高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。普世的例子： 目前微服务盛行， 之前大而统一的系统中都是系统内的方法调用， 而将这个大而统一系统拆解成多个微服务后， 就会出现跨系统的方法调用， 怎么解决这种跨系统的方法调用呢， 如果对java熟悉的话， 第一个想到的就是Java RMI远程方法调用， 而用过它的同学都知道， 使用繁杂。 而Dubbo就适合解决跨系统的方法调用，并天然的支持分布式， dubbo分成服务的提供者provider和服务的消费者consumer, provider负责到注册中心（一般是zookeeper）注册服务， consumer向注册中心订阅服务。 dubbo除了提供了原生的注册服务和订阅服务的方法， 还和spring进行了结合， 只需要通过简单的配置就可以实现服务的注册或者订阅。文档： http://dubbo.io

可以把订单提交操作进行划分成主流程和附属流程， 主流程同步， 附属流程异步。 比如主流程是校验参数，扣减库存， 然后将订单信息落库， 附属流程是：给用户添加积分，主流程执行完毕后就认为订单创建成功，并把结果返回给前端。 而附属流程可通过在订单创建成功后发送mq通知积分系统给用户添加积分， 保证最终一致性即可。

楼主意思是对扫码支付的用户进行分析吗？ 比如分析用户地理位置分布， 年龄分布， 使用支付工具等等

我的理解： 如果出现异常将MQ的producer发送消息回滚即可吧， 消息不发送就没有后面consumer消费的事情了。

XSS的概念： 攻击者往页面中插入恶意的js代码， 当用户打开页面时， 被插入的恶意代码会被执行， 进而达到攻击者控制浏览器的目的。解决方法： 防止XSS攻击可从两个方面出发， 分别是： 输入和输出。 输入即对请求的参数， 尤其是用户输入的参数要进行过滤， 防止恶意用户传js脚本到系统中； 输出即请求返回值进行转义， 比如

Spring + Dubbo 是很经典的微服务架构。 Dubbo作为一个分布式RPC架构来解决微服务之间的方法调用问题；Spring作为一个容器来管理服务中Bean的生命周期，其中Dubbo的服务提供者和消费者也可作为bean交由Spring统一管理。

这个要看你使用的是消息队列是否支持了！比如kafka是可以支持从头开始消费的， 需要在对应的spring-kafka消费者客户端配置以下参数：

如果同样的sql的话， 通过mybatis查询会比直接通过客户端工具查询更快些。

目前市面上有些分布式事务的产品， 比如阿里的GTS， 但是否要使用分布式事务要根据系统所处的场景判断。 如果要求强一致性并且并发量不高的情况下可以考虑使用这些分布式产品。 如果你的系统所处的是一个高并发的场景（比如TPS达到了几十万）， 这个时候市面上的分布式事务产品很难满足需求的（很多分布式事务的产品强依赖业务底层的数据库， 高并发时底层数据库很容易成为瓶颈）， 这个时候就不得不考虑使用消息队列+补偿机制来解决了。

如果打开的网页是自己的网页，可以通过Request中的User-Agent来判断是来自哪个客户端或者浏览器。 如果不是你也可以在外面包一层， 扫码先到你自己的服务上，然后在进行302跳转。 这样你就可以通过Request中的User-Agent来判断是来自哪个客户端或者浏览器

google zxing包， 提供了二维码的生成和解析方法。