本文先提供一个没有采用的方式--采用事务加select for update的形式
这么做呢就有个非常严重的问题,--- 同一时刻只有一个有效服务
如果A系统拿到了数据,开始了事务但是没提交,那么B系统同样的条件也会查到同一批还没处理好提交的数据,此时B系统该查询线程就会阻塞等待A提交事务.这么看问题就来了,这里虽然保障了同一时刻只有一个服务可以拿到并处理一批数据,但是也导致了效率特别低,而且后面 无论扩展多少服务应用都没啥用
步骤解释:
我这里只写了大致的方案,一些redis高可用以及数据幂等性自己考虑去.
这种方式是 我觉得最好的方案 了,完全保障了每个服务每次 处理 mysql的数据都是 互不相同的数据 ,完全 避免了竞争 问题.
但是我们目前没有用这种方案,原因是...目前我们redis内存只申请到一个比较小的内存,而 zset采用的跳跃表结构虽然保障了数据查询非常快速,但是也非常占用内存 ,预估了一下按照我们的数据量起码要存储300万数据,用到的内存量是 3~4G 之间,好家伙直接把我们所有内存都用了,其他服务还用个屁...而且这玩意为了保障数据安全,不进行数据淘汰起码还要留个1G空闲安全空间....那肯定就用不了了
如果你们的服务 数据量够小 或者 内存够大 ,redis又做到了 高可用,高可靠 ,那么我还是 十分推荐 用这种方案,毕竟很多服务都是 性能为王!
处理大量数据并发操作可以采用如下几种方法:
1.使用缓存:使用程序直接保存到内存中。或者使用缓存框架: 用一个特定的类型值来保存,以区别空数据和未缓存的两种状态。
2.数据库优化:表结构优化SQL语句优化,语法优化和处理逻辑优化分区分表索引优化使用存储过程代替直接操作。
3.分离活跃数据:可以分为活跃用户和不活跃用户。
4.批量读取和延迟修改: 高并发情况可以将多个查询请求合并到一个。高并发且频繁修改的可以暂存缓存中。
5.读写分离: 数据库服务器配置多个,配置主从数据库。写用主数据库,读用从数据库。
6.分布式数据库: 将不同的表存放到不同的数据库中,然后再放到不同的服务器中。
7.NoSql和Hadoop: NoSql,not only SQL。没有关系型数据库那么多限制,比较灵活高效。Hadoop,将一个表中的数据分层多块,保存到多个节点(分布式)。每一块数据都有多个节点保存(集群)。集群可以并行处理相同的数据,还可以保证数据的完整性。
拓展资料:
大数据(big data),指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合,是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。
在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》中大数据指不用随机分析法(抽样调查)这样捷径,而采用所有数据进行分析处理。大数据的5V特点(IBM提出):Volume(大量)、Velocity(高速)、Variety(多样)、Value(低价值密度)、Veracity(真实性)。
参考资料:网页链接
在服务器、数据库并发宽容度
设置范围内执行数据同时写入一般不会有问题,如果是超过
并发数
限定值会出现延迟、数据丢失一部分、或死机情况,所以建议在做负责载均衡时要考虑到实际数据量与并发量情况进行合理设置。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)