胃吸收分行场景和客户做好高并发海量数据基础.docxVIP

7 - 胃吸收分行场景和客户做好高并发海量数据基础 高并发海量数据处理，在我经历中，这是两个事情但又相关连的。高并发怎么处理，这个问题应该是具体问题具体分析，应该是找到瓶颈再做针对处理。不可能全部做升级，那样成本太高了。一般是一步步的解决。在说具体的方案之前，我说下之前的经历，一个典型的案例。朋友所在的公司是一家互联网保险公司，遇到的问题是：某款产品(打折较多的)会出现加载不成功，然后用户下单时报数据库异常，应该是 并发导致事务异常插入不成功。用工具测试：QPS在100到500之间，硬件资源高峰不到30%。这个数据说明我们可以从应用本身做优化。我建议他第一步把PV高的页面做页面缓存（因为是产品，改动不大），他们的主站是net开发的，用的框架是4.0,且用的是MVC。所以很简单的在action中加上outputcache特性（net称特性，java 叫注解，有意思不？）就可以了。当然还要设置两个比较重要的参数的，这个产品详情页是公用的也就是说所有产品都是打开在这个页面展示。所以我们得设置按产品id作为参数缓存，并且缓存过期时间设置比峰值访问大一些。第二步，使用消息队列异步下单，这个改动比较大的。这个方案，是我之前设计过一个秒杀架构总结出来的。下单的服务端（消息消费者）用的是java,因为他们公司有意向把主站改为java的。客户端（消息产生者）即net下单站点。消息队列使用的是rabbitmq，选择其有几个比较的指标的，rabbitmq采用的是amqp协议，无需装其他插件只需装erlang环境，跨平台比较泛（手持设备需要下单），开源，收发消息比较平均，且队列可以持久化，这就不怕消息丢失，解决下单不成功时可以再次下单；还有个优点可以设置出错的消息可以重复投递，我建议他设置重复投递3次，3次不成功人工干预，放到另一个暂存队列，并通知管理员人工处理。3次基本可以杜绝并rabbitmq发引起的悲观锁，若都不成功，证明数据有问题的。其他MQ优势不大，MSMQ微软自己的，不能跨平台，消息大小限制4M。ActiveMQ，JAVA自己的MQ，不过性能不是那么理想跟MSMQ差不多的性能。ZeroMQ,这个性能超乎想象的，发送消息比其他可以甩几条街的，可惜不能持久化，用来做即时通讯是不错的。按这个改动朋友公司跑了半年后，他又找到我，现在有个这样的问题：C#高并发产生消息有瓶颈，至少比java少一半性能，也就是说c#产生100条消息，java可以产生200条，是不是C#性能比java差？对于这个问题我顿时有点蒙的，两者性能不会相差这么大的。两者性能之争一直是两大开发团队讨论的焦点矛盾，咱不纠结这个问题，以我的经验，两种语言我都有用过，性能不会相差这么大的，一定是代码有问题的。于时我去他公司，用他的电脑，做了次代码走查，当然我只看发送消息那部份，业务我可不关心的。哥们的代码规范做得不错的，定义了接口ISender，再定义RabbitMQSender来实现，用的类库RabbitMQ .NET来连接MQ。且自己写了个均衡策略，开始我原以为问题出个这里，代码看了几遍也没有可疑的地方，注释掉跑也没有解决问题。没办法只有出大招了，VS自带有个性能探测工具，感谢VS IDE有个这么好的工具，解决很多代码失误引起的性能问题。哥们装的是vs2010,没有vs自带性能探测工具，我给他装了个vs2013。多说几句，我比较喜欢VS这个IDE，且最喜欢这个性能测试工具，这是其他IDE没有的。这个工具可以测试每一层每个方法调用的开销，还有个web性能测试工具也不错的。要是这的个IDE能支持JAVA，那么真可以说一统江湖了。好了废话不说了，运行起来，正常的跑一次流程，抽丝剥茧的，使用次数多了也有经验了，马上发现一个异常，发送完后还有很大性能开销，占了86%，展开代码进去看到，重写了析构函数，做一些变量回收工作，且写一句GC.Collect()。哥们的思路了发送一次完后，清理一下内存碎片，给下次得到更多的内存使用。咋一看，这不能说有错，很正常，很多人都会这样写的，特别是有IO文件流操作的时候。可是GC.Collect大家要知道一点，他一回收，我们原先创建连接到MQ那些路由都会给回收掉了，导致每次都要重新寻址创建握手链接的，这个很消耗时间的，几乎需要500-800ms完成这个过程（机器不一样，内网的防火墙路由策略不一样会有影响这个时间）。注释这句代码，跑起来一切正常了。在这里提醒一下大家，GC.Collect这个方法不需要随便调用的，这个交给系统处理就行了，现在内存那么便宜。我们使用是的C#是托管语言，内部有机制去管理内存的，他会在觉得内存不够用的时候适时出手清理掉已过期的数据的，要想具体了解原理实现过程，可以看一下这本书《CLR VIA C#》。下面说一下