12 2018 档案
摘要：如何实现mysql的读写分离？ 就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。 MySQL主从复制原理的是啥？ 主库将变更写binlog日志，然后从库连接到主库之后，从库有一个IO线程，将主库的binlog日志拷贝到自己本地
阅读全文
摘要：数据库自增id： 这个就是说你的系统里每次得到一个id，都是往一个库的一个表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个id。拿到这个id之后再往对应的分库分表里去写入。 这个方案的好处就是方便简单；缺点就是单库生成自增id，要是高并发的话，就会有瓶颈的； 适合的场景：你分库分表就俩
阅读全文
摘要：设定好几台数据库服务器，每台服务器上几个库，每个库多少个表，推荐是32库 * 32表。 比如4台服务器，每台服务器上8个库，每个库32张表。 路由的规则，orderId%32 = 库，orderId / 32 %32 = 表 扩容的时候，申请增加更多的数据库服务器，装好mysql，倍数扩容，4台服务
阅读全文
摘要：停机迁移方案 网站或者app挂个公告，说0点到早上6点进行运维，无法访问 接着到0点，停机，没有流量写入了，此时老的单库单表数据库静止了。然后你之前得写好一个导数的一次性工具，此时直接跑起来，然后将单库单表的数据读出来，写到分库分表里面去。 导数完了之后，就ok了，修改系统的数据库连接配置啥的，包括
阅读全文
摘要：单表到几百万的时候，性能就会相对差一些了，你就得分表了。 分表是啥意思？就是把一个表的数据放到多个表中，然后查询的时候你就查一个表。比如按照用户id来分表，将一个用户的数据就放在一个表中。然后操作的时候你对一个用户就操作那个表就好了。这样可以控制每个表的数据量在可控的范围内，比如每个表就固定在200
阅读全文
摘要：系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以抗高并发么。 缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并
阅读全文
摘要：tomcat + redis 这个其实还挺方便的，就是使用session的代码跟以前一样，还是基于tomcat原生的session支持即可，然后就是用一个叫做Tomcat RedisSessionManager的东西，让所有我们部署的tomcat都将session数据存储到redis即可。 在tom
阅读全文
摘要：分布式协调 这个其实是zk很经典的一个用法，比如，A系统发送个请求到mq，然后B拿到消息消费之后处理了。那A系统如何知道B系统的处理结果？ 用zk就可以实现分布式系统之间的协调工作。A系统发送请求之后可以在zk上对某个节点的值注册个监听器，一旦B系统处理完了就修改zk那个节点的值，A立马就可以收到通
阅读全文
摘要：假如你有个服务提供一个接口，结果这个服务部署在了5台机器上，接着有个接口就是付款接口。 然后用户在前端上操作的时候，不知道为啥，总之就是一个订单不小心发起了两次支付请求，然后这俩请求分散在了这个服务部署的不同的机器上，结果造成一个订单扣款扣两次。 所谓幂等性，就是说一个接口，多次发起同一个请求，你这
阅读全文
摘要：dubbo负载均衡策略 random loadbalance 默认情况下，dubbo是random load balance随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。 roundrobin loadba
阅读全文
摘要：dubbo支持的通信协议 dubbo协议 dubbo://192.168.0.1:20188 默认就是走dubbo协议的，单一长连接，NIO异步通信，基于hessian作为序列化协议 适用的场景就是：传输数据量很小（每次请求在100kb以内），但是并发量很高 为了要支持高并发场景，一般是服务提供者就
阅读全文
摘要：dubbo工作原理 第一层：service层，接口层，给服务提供者和消费者来实现的 第二层：config层，配置层，主要是对dubbo进行各种配置的 第三层：proxy层，服务代理层，透明生成客户端的stub和服务端的skeleton 第四层：registry层，服务注册层，负责服务的注册与发现 第
阅读全文
摘要：为什么要将系统进行拆分 如果不拆分 一个大系统几十万行代码，20个人维护一份代码，代码经常改着改着就冲突了，各种代码冲突和合并要处理，非常耗费时间； 自己改动代码后，可能影响别人的。 每次上线都要做很多的检查，很多异常问题的处理。 拆分了之后 几十万行代码的系统，拆分成20个服务，平均每个服务就1~
阅读全文
摘要：问题描述：多客户端同时并发写一个key，可能本来应该先到的数据后到了，导致数据版本错了。或者是多客户端同时获取一个key，修改值之后再写回去，只要顺序错了，数据就错了。 一个key的值是1，本来按顺序修改为2,3,4，最后是4，但是顺序变成了4,3,2，最后变成了2. 首先使用分布式锁，确保同一时间
阅读全文
摘要：最经典的缓存+数据库读写的模式：cache aside pattern Cache Aside Pattern 读的时候，先读缓存，缓存没有的话，那么就读数据库，然后取出数据后放入缓存，同时返回响应 更新的时候，先删除缓存，然后再更新数据库 （很多地方都说应该先更新数据库，再删缓存） 为什么是删除缓
阅读全文
摘要：缓存雪崩 如何应对缓存雪崩 首先要保证redis的高可用，可以使用redis cluster，开启redis持久化，redis之前要使用本地缓存，请求先走本地缓存，没找到再走redis 如果还是出现了缓存雪崩，开启限流组件，比如每秒5000个请求，只让其中2000个请求走数据库，剩下3000个请求走
阅读全文
摘要：redis cluster redis cluster是Redis的分布式解决方案，在3.0版本推出后有效地解决了redis分布式方面的需求 自动将数据进行分片，每个master上放一部分数据 提供内置的高可用支持，部分master不可用时，还是可以继续工作的 支撑N个redis master no
阅读全文
摘要：持久化的意义 redis持久化的意义，在于故障恢复 比如你部署了一个redis，作为cache缓存，当然也可以保存一些较为重要的数据 如果没有持久化的话，redis遇到灾难性故障的时候，就会丢失所有的数据 如果通过持久化将数据搞一份儿在磁盘上去，然后定期比如说同步和备份到一些云存储服务上去，那么就可
阅读全文
