[投机取巧]一个单机服务的并发问题

最近在处理一个单体应该的时候遇到了并发问题

出现并发问题的伪代码：

String redisKey="ORDER_CURRENT_KEY";
        String orderCurrentKey = redisUtils.get(redisKey);
        if (Integer.valueOf(orderCurrentKey)<100) {
            redisUtils.incr(redisKey ,1 );
            System.out.println("服务器只能同时处理100个请求");
        }else {
            System.out.println("当前同时处理数已满");
            return null;
        }

压力测试的并发为每秒1000，当前线上生产环境，高峰期每秒2000，日常每秒50

伪代码第二行：

假设会进入300个同时获取，那这300个线程，就会通过第三行的判断，变为同时处理了300个请求，导致测试环境程序奔溃。

而且最终redis中的值是 ORDER_CURRENT_KEY 的值是300.

简单并发问题，测试服务器配置较低...容易出现各种问题；

想法：

解决办法有：

• 加锁，对在获取值，到对比加锁，但是会严重影响程序的并发能力
• 依赖redis或者zookeeper做分布式锁，redis由于知识储备问题，没有实现；依赖zookeeper，就因为一个锁，依赖多一个组件，不划算！
• 最终，使用了一种投机取巧的办法！

看伪代码：

　　　　Long lockOrder = redisUtils.incr("ORDER_CURRENT_LOCK_KEY",1);
        String redisKey="ORDER_CURRENT_KEY";
        if (lockOrder<100) {
            redisUtils.incr(redisKey ,1 );
            System.out.println("服务器只能同时处理100个请求");
        }else {
            System.out.println("当前同时处理数已满");
            return null;
        }

思路是，加多一个redis键值对；

利用 redisUtils.incr(key,1);内部的计算方法！还有redis天然的单线程！

所以算出来值不会存在重复值！并发再高也不会！lockOrder值就是请求数！

lockOrder ！！！既然不重复！

在第三行对比的时候，lockOrder 的值是：0-99，都会进入服务的内部处理！其他都直接返回结果！

好像完美解决！

反正现在压力测试，并没有出现过超出100的同时请求处理！

确实有点投机取巧，利用redis的单线程特性！

确实有点投机取巧，但是并不是每个公司，都会搭建集群，都部署超高配置服务器；

这里生产环境只有一台8核16G的服务器，所有服务都部署在上面，不过业务是非常简单的而已。。

可能后续会拓展吧.......什么高可用，高性能，更高并发5K-10K。。。后续再续集进行个人的知识储备吧。