解决方案

上面是一张意向表，只要用户发布一条有关证券的意向，那么对应意向的出借或者借入的量就要有对应的变化，现在需要将数据放在redis中
有一些数据需要不断的更新
根据证券名称分组，统计出借数量一共是多少，借入数量一共是多少

初步解决方案：每次去数据库进行一次分组查询再覆盖redis中的数据，这样不是很好的方案，每天意向发布甚至几万条都有可能，这样全量操作不好

这里考虑的是做增量处理，只要用户发布一条，就直接去对应的数量上面去加，而不是整体去数据库重新查询
分组查询

——————————————————————————————————————————————————————————
我感觉你并不知道redis的作用是什么：redis是用来减少对数据库的压力的，防止用户直接访问数据库用的，提高访问效率
解决方案：我在数据库创建一张临时表，专门记录某个证券的借入量是多少 借出量是多少，每次用户发布证券意向，我就去这个临时表去更新数量，然后再查询出来放入到redis中，这样扫描的意向的数量就少了，现在国内一共只有4000多的证券，那么也就只要扫描4000条数据就行了,我的这个方案需要扫描的数据变少了,最多4000行数据.
意向表是以意向id为主键,同一个证券 我可以发布一个亿的意向,大家都可以发布这个证券的意向,临时表类似做了一个统计,到时候直接到统计表去获取想要的数据.
如果是直接对数据库进行操作的话，会存在这样一个场景，可能会对表字段进行一亿次的新增，会存在需要扫面一个亿的数据的问题
那么我们现在不去group by分组这个表，而是直接来一个意向 我就对应的那个证券加减数量，然后直接单表查询塞redis
查询块是一方面，一开始 用户量不大 也就是用户访问量也不会大，那么我们也可以不增加缓存 当然了 不增加缓存速度上会稍微差点 但是也差不到哪里去 用户还是可以接受的，当用户量不断的增加 我们的单表已经无法承受了，那么我们就可以考虑其他方案了 首先单服务器接受的用户访问量也是有限的 如果达到每秒500个请求 那么我们肯定是要考虑布置多个节点来实现负载均衡 来保护我们的程序，也可以限流，但是限流只是下下策。我们布置多个节点，那么问题又来了 我们服务器节点不可能无限制的增加呀，而且我们的数据库的数据也要做备份处理，万一用户量一增加 导致数据库死锁甚至宕机那岂不是完蛋，那么我们就使用主从备份，并使用读写分离来实现抵挡用户的访问量，但是 用户量还在不断的增加，那么我们怎么办呢，再加一个缓存，让用户不走数据库的服务，大部分只要查询一次就好，那么这样就又解决了用户量大 并发量大的问题，现在的各个方案都是这样不断的递进的，看用户量和并发量的多少来增加服务的节点，一般缓存的节点是固定的