Category: Distributed Architecture
高并发下怎么防止数据重复? 多线程并发消费如果在极短的时间内,连续发送重复的消息,就会被不同的线程消费。即使在代码中有这样的判断:
|
Product oldProduct = query(hashCode); if(oldProduct == null) { productMapper.insert(product); } |
在插入数据之前,先判断该数据是否已经存在,只有不存在才会插入。但由于在并发情况下,不同的线程都判断商品数据不存在,于是同时进行了插入操作,所以就产生了重复数据。 方案: 基础系统将消息改成单线程顺序消费 唯一索引(不适用软删除) 分布式锁 insert on duplicate key update insert … ignore 加一张防重表(适用软删除)
消息顺序性,究竟为什么这么难? 面试官问:消息被重复消费,怎么避免?有什么好的解决方案?
We got escalation today, a lot of services are very slow or stop working. Our Oracle database(10g) admin has found that there are a huge number of unclosed sessions in the Oracle database. In...
程序员硬核“年终大扫除”,清理了数据库 70GB 空间 在没有删除单个索引或删除任何数据下,最终释放了超过 70GB 的未优化和未利用的空间,还意外释放 20GB 未使用索引空间。
1. 背景 几年前我曾经服务过的一家电商公司,随着业务增长我们每天的订单量很快从30万单增长到了100万单,订单总量也突破了一亿。当时用的Mysql数据库。根据监控,我们的每秒最高订单量已经达到了2000笔(不包括秒杀,秒杀TPS已经上万了。秒杀我们有一套专门的解决方案,详见《秒杀系统设计~亿级用户》)。不过,直到此时,订单系统还是单库单表,幸好当时数据库服务器配置不错,我们的系统才能撑住这么大的压力。 业务量还在快速增长,再不重构系统早晚出大事,我们花了一天时间快速制定了重构方案。 重构?说这么高大上,不就是分库分表吗?的确,就是分库分表。不过除了分库分表,还包括管理端的解决方案,比如运营,客服和商务需要从多维度查询订单数据,分库分表后,怎么满足大家的需求?分库分表后,上线方案和数据不停机迁移方案都需要慎重考虑。为了保证系统稳定,还需要考虑相应的降级方案。
SQL连接图解演示-共七页 数据库底层数据结构与数据库索引类型 跳表,哈希索引,SSTable,LSM树,B树,倒排索引,R树,后缀树。 如果MySQL磁盘满了,会发生什么?还真被我遇到了! 要进行磁盘碎片化整理。原因是datafree占据的空间太多,看看自己的系统的datafree大不大 show table status from 表名; 100G内存下,MySQL查询200G大表会OOM么? MySQL中ORDER BY与LIMIT 不要一起用,有大坑 如果order by的列有相同的值时,mysql会随机选取这些行,为了保证每次都返回的顺序一致可以额外增加一个排序字段(比如:id),用两个字段来尽可能减少重复的概率。
数据库读写分离的这些坑,让我一脸懵逼! 「由于数据库同步存在延时,这就导致数据同步的这段时间,主从数据将会不一致,从库无法查询到最新的数据。」 最优解:缓存路由大法
GeoHash 将二维的经纬度转换成字符串,快速选取最近的POI。
MQ,很多的应用场景,是消息的订阅发布,是系统上下游的解耦,MQ的还有一个典型应用场景是缓冲流量,削峰填谷,本文将简单介绍下,MQ要怎么实现缓冲流量,削峰填谷。 站点与服务上下游之间,一般如何通讯? 有两种常见的方式。 一种是“直接调用”,通过RPC框架,上游直接调用下游。 一种是“MQ推送”,上游将消息发给MQ,MQ将消息推送给下游。