活着，就一直在忙碌，从未有停歇。

活着，就一直在忙碌，从未有停歇。

最近，忙里偷闲，整理本身的技术知识体系，随便写写，权当Mark。

问题界定

发现问题，解决问题。

案例一：高并发和MongoDB交互

问题描述：Job跑起价时，CPU Load很高。

Dump分析：查看线程调用栈信息，有42个线程在以下状态

说明稍微高一点并发时，记录日志会有问题，反编译能够看到DoAppend时会lock住当前对象。

而代码中采用一个实例，且设置的缓冲区大小为2，重写的SendBuffer方法中和MongoDB交互。

因此，这里是因为频繁的和MongoDB交互引发的高CPU Load。

 

优化方案：

1.改变缓冲区大小，设置一个较大的值。但若是日志不够多，可能好久写不出来。

2.自定义一个日志池，根据时间和个数的双重维度控制，异步批量的和MongoDB交互。

案例二：接口耗时较多

问题描述：CPU Load很高。

Dump分析：

先查看线程数，再打印出每一个托管线程的调用栈信息，没有发现明显问题。

继续，查看线程的耗时，发现有两个线程耗时为30秒，从调用栈信息查看，是同一个接口。

对该接口作压力测试，5个并发时CPU在90%以上，因此是因为接口耗时较多，致使并发时高CPU Load。

 

性能分析：

用VS Analyze Tool对接口作性能分析，发现重复调用了从redis中取某个特定缓存数据的方法

跟踪代码，发现对于相同的缓存数据，用两种方式重复取： 
1.循环，取单个缓存。 
2.一次取全部缓存。

因此这里取重复了，多了一倍的耗时，经过调试能够验证这个结论。因此，首先要剔除重复。

以后，查看为什么从Redis取缓存如此慢，缘由是以json字符串格式存取Redis的，因此取时须要反序列化，能够针对这点再考虑优化存取方案。

基础架构

Quartz.NET、ActiveMQ、Unity、Autofac、Git等。

   

其中，进程间通讯，除了WebAPI，还包括：

        

分布式系列

Hadoop没实践过，只是以前看看书而已，都快忘了。。。

 

分层

 

H5和ASP.NET MVC都不是特别熟，用户表现层就不说哈~~

数据持久层

SQL Server、MySQL、Mongodb等。

 数据仓储层

经过ADO.NET或EF等ORM工具，实现和数据库的交互操做。

数据缓存层

使用Memcached、Redis或自建缓存系统。

业务领域层

C#

数据结构与算法设计

代码仓库

 

细节，有时间再慢慢道来吧。。