现有020的系统架构走库存,取券通过Fetch前n条来实现买n张优惠券,但此做法在高并发时有严重的性能问题,性能问题主要体现在数据库。
为了优化此性能,系统改为redis,走队列模式,即生产者消费者。
以下是自己做性能测试一此小杂记。
1 public static void testEnqueue() 2 { 3 Console.WriteLine("开始运行"); 4 var stopWatch = new Stopwatch(); 5 stopWatch.Start(); 6 for (int i = 0; i < 100000; i++) 7 { 8 redisClient.EnqueueItemOnList("o2olist", i.ToString().PadLeft(12, '0')); 9 }10 var time = stopWatch.ElapsedMilliseconds;11 stopWatch.Stop();12 //125935,每秒可写800笔13 Console.WriteLine(string.Format("耗时:{0}毫秒", time));14 Console.ReadKey();15 }
ps:后台程序定时执行,考虑用java写在守护进程处理,由crontab调度
1 public static void testDequeue() 2 { 3 Console.WriteLine("开始运行"); 4 var stopWatch = new Stopwatch(); 5 stopWatch.Start(); 6 var a = redisClient.GetListCount("o2olist"); 7 //队列操作之出队 8 for (int i = 0; i < a; i++) 9 {10 Console.WriteLine(redisClient.DequeueItemFromList("o2olist"));11 }12 var time = stopWatch.ElapsedMilliseconds;13 stopWatch.Stop();14 //141538每秒可取71415 Console.WriteLine(string.Format("耗时:{0}毫秒", time));16 Console.ReadKey();17 }
ps:此情况基本不会出现在我现有o2o项目的场景,仅测试下
1 public static void testDequeue2() 2 { 3 Console.WriteLine("开始运行:" + DateTime.Now.ToString("HH-mm-ss:fff")); 4 Console.ReadKey(); 5 var stopWatch = new Stopwatch(); 6 stopWatch.Start(); 7 //四台机器买券并发估计10笔/s 8 for (int i = 0; i < 4 * 10; i++) 9 {10 new Thread(() =>11 {12 try13 {14 RedisClient redisClient1 = new RedisClient(host, port);15 while (true)16 {17 var a = redisClient1.DequeueItemFromList("o2olist");18 if (a == null)19 {20 Console.WriteLine(DateTime.Now.ToString("HH-mm-ss:fff"));21 break;22 }23 else24 Console.WriteLine(a);25 }26 }27 catch (Exception ex)28 {29 Console.WriteLine(ex.Message);30 //31 //File.AppendAllText("c:\\e.log", DateTime.Now.ToString("HH-mm-ss:fff") + "\r\n" + ex.Message + ex.InnerException);32 }33 }34 ).Start();35 }36 //耗时38s,2631笔每秒37 Console.ReadKey();38 }
ps:目前生产是4台机器,按每秒10笔并发计算
结论:
1、入队性能800笔/s
2、单线程出队性能714笔/s
3、40并发2631笔每秒
ps:
环境说明:reids部署在32位suse上,程序是我本地用.net写的
后续:
1、入队要做一个守护进程去定时处理,考虑在linux放个java程序由contab调度。
2、出队没有券时的业务场景考虑