yscoder的博客

一、秒杀业务为什么难做 1）im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）； 2）微博系统，每个人读你关注的人的数据，一个人读多个人的数据； 3）秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据，多个人读一个数据。例如：小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。 又例如：12306抢票，票是有限的，库存一份，瞬时流量

本文主要讨论这么几个问题： （1）“缓存与数据库”需求缘起 （2）“淘汰缓存”还是“更新缓存” （3）缓存和数据库的操作时序 （4）缓存和数据库架构简析一、需求缘起 场景介绍 缓存是一种提高系统读性能的常见技术，对于读多写少的应用场景，我们经常使用缓存来进行优化。 例如对于用户的余额信息表account(uid, money)，业务上的需求是： （1）查询用户的余额，SELECT m

一、缘起 当数据库的数据量非常大时，水平切分和垂直拆分是两种常见的降低数据库大小，提升性能的方法。假设有用户表： user( uid bigint, name varchar(16), pass varchar(16), age int, sex tinyint, flag tinyint, sign varchar(64), intro varchar(256) …); 水

一、问题域 nginx、lvs、keepalived、f5、DNS轮询，每每提到这些技术，往往讨论的是接入层的这样几个问题： 1）可用性：任何一台机器挂了，服务受不受影响 2）扩展性：能否通过增加机器，扩充系统的性能 3）反向代理+负载均衡：请求是否均匀分摊到后端的操作单元执行二、上面那些名词都是干嘛的 由于每个技术人的背景和知识域不同，上面那些名词缩写（运维的同学再熟悉不过了），还是花1

本文主要讨论这么几个问题： （1）数据库主从延时为何会导致缓存数据不一致 （2）优化思路与方案一、需求缘起 在只有主库时，通过“串行化”的思路可以解决缓存与数据库中数据不一致。而“在主从同步，读写分离的数据库架构下，有可能出现脏数据入缓存的情况，此时串行化方案不再适用了”，这就是本文要讨论的主题。二、为什么数据会不一致 为什么会读到脏数据，有这么几种情况： （1）单库情况下，服务

需求缘起 大部分互联网的业务都是“读多写少”的场景，数据库层面，读性能往往成为瓶颈。如下图：业界通常采用“一主多从，读写分离，冗余多个读库”的数据库架构来提升数据库的读性能。 这种架构的一个潜在缺点是，业务方有可能读取到并不是最新的旧数据： （1）系统先对DB-master进行了一个写操作，写主库 （2）很短的时间内并发进行了一个读操作，读从库，此时主从同步没有完成，故读取到了一个旧

一、什么是高并发 高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要20

列出所有的容器 IDdocker ps -aq停止所有的容器docker stop $(docker ps -aq)orsudo docker stop $(sudo docker ps -aq)删除所有的容器docker rm $(docker ps -aq)orsudo docker rm $(sudo docker ps -aq)删除所有的镜像doc...