大数据量的批处理的一些思考

大数据量的思考：

        针对涉及金额的大批量用户的处理，首先需要评估数据的量级，针对同一用户可能存在N条记录的同时，需要准确的计算用户涉及提现、兑换金额的扣减带来的程序的复杂度，计算首先具备一定的复杂度，其次更新需要存在事务。

        先说说我现在的思路：

        针对同一用户我加了redis的锁，锁住是当前提现或者兑换操作，同一用户的账户的金额还是可以不断的流入，但是体现和兑换只能排队进行，目前尚不清楚并发情况下性能的瓶颈会是多少；原来未接手之前，原开发是for循环中一条一条去更新，数据库的记录，考虑到数据库连接池的数量以及性能的损耗，我使用的是redis加锁机制，在锁的内容中，全量读取该用户的所有过期的金额，然后与该用户的的在在线库中的金额进行的两层for进行的对比，形成一个需要扣减的值，一个是在线库金额扣减的map，一个是过期表中的一个list的对象，首先内部的计算逻辑是当前具备一定的复杂度的，可是从代码角度来看可能就15行即可处理掉当前的逻辑处理关系，锁的内容还不仅仅包含这些，原有逻辑中还有各种针对该扣减金额的操作，目前看是同一个数据库，因此事务上应该是能够保障的，如果抛出异常或者处理中断，所有的数据都会回滚；

        针对以上的做法，经过反思首先存在几个问题：

        1、是否有必要加redis锁，更新计算出来的金额，通过数据库的行锁是不是就能够解决该问题，行锁的性能到底低所少，目前我自己是没有概念的，因为没有数据支撑，计算的金额在扣减的时候使用当下的库中金额直接扣减，那么只要能够扣减成功则返回，扣减失败则报错，突然想到一个问题，过期的表中，扣减完我是直接归0的，这个操作是错误的，应该还是计算出具体的扣减金额然后使用数据的当下的值进行对应的扣减，明天需要澄清该问题

        2、针对大数据量的问题，首先错误的是处理的思维，数据量的越大那么处理应该是通过批处理的思维去做，或者一部分一部分的去处理，全量的读取操作本身就是巨大的浪费了内存以及性能，并且处理方式上，首先如果出现人数的并发，数据库的连接数首先是有限的，本来就是要排队处理，那么针对并发的处理按道理就应该是队列模式，抓取一部分，扔给另外一个再去处理一部分，如果处理堵塞则等待释放在继续抓取继续处理，从本质上可以控制内存的量

        3、内存处理会好与多次的读写，IO的性能也会成为瓶颈，这里面就会存在一个平衡的问题

        4、此次涉及到使用了redis锁，涉及技术问题，需要深耕原理，自己如果使用技术，尤其是新的技术（其实也是相对新公司而言，原来的公司因为有架构支撑，其实我基本上就是处于使用即可，后面又团队帮忙解决技术壁垒），现在自己搞了，确实需要有原理控的思维，大大咧咧的处理方式已经不适合当下的处理事情的方式

        5、抛弃原本的思维，抛弃原本的自己，自己的优势是涉及的系统多，看到的多，广度是有的，但是深度没有达到要求，还需要继续。

今天理解一下redis锁：

原文：redis分布式锁的8大坑【Redis分布式锁】__花野的博客-CSDN博客_redis 分布式锁有什么缺陷