RichardGeek的博客

逆流程 场景下 处理状态机变化的方案

后端开发规约（示例代码举例版）

最全的权限系统设计方案

架构设计方案

本文后续不断修改更新ing

elk 联通性验证

利用K8s 搭建ELK 环境

理论部分

原文地址：https://hiddenpps.blog.youkuaiyun.com/article/details/110602671本文带大家深度分析数据库与缓存的双写问题，以供大家参考。哪类数据适合缓存缓存量大但又不常变化的数据，比如详情，评论等。对于那些经常变化的数据，其实并不适合缓存，一方面会增加系统的复杂性（缓存的更新，缓存脏数据），另一方面也给系统带来一定的不稳定性（缓存系统的维护）。但一些极端情况下，你需要将一些会变动的数据进行缓存，比如想要页面显示准实时的库存数，或者其他一..

转发自：JAVA葵花宝典公众号文章目录一. 常用的两种缓存技术的服务端特点1. Memcache服务端2. Redis服务端二、缓存一致性问题1. 并发读写导致的一致性问题2. 主从同步延时导致的一致性问题3. 缓存污染导致的一致性问题三、缓存一致性问题解决方案1. binlog+消息队列+消费者del cache2. 从库binlog+消息队列+消费者del cache3. 更新后key升级四. 命中率问题五.缓存穿透/缓存击穿六.缓存雪崩...

1一致性哈希失效处理其实比较容易出现的问题是漂移的问题：某个节点失效了，缓存都漂到下个节点了；然后一会它又恢复了，这时候它就有脏数据了。解决办法一是每个节点引入集群。不用集群想彻底解决这个问题，可能需要引入第三方健康检查组件，如Consul，发现节点不稳定立即删除下线。2缓存命中率及单一热点问题一致性哈希解决的是某节点宕机后缓存失效的问题，只会导致相邻节点负载增加。但是因为宕机后需要重新从数据库读取，会导致此时缓存命中率下降及db压力增加。也无法避免单一热点问题。某一数据被海量请求，不论怎么哈希

前言分布式环境下应对高并发保证服务稳定几招，按照个人理解，优先级从高到低分别为缓存、限流、降级、熔断，每招都有它的作用，本文重点就讲讲限流这部分。坦白讲，其实上面的说法也不准确，因为服务降级、熔断本身也是限流的一种，因为它们本质上也是阻断了流量进来，但是本文希望大家可以把限流当做一个单纯的名词来理解，看一下对请求做流控的几种算法及具体实现方式。为什么要限流其实很好理解的一个问题，为什么要限流，自然就流量过大了呗，一个对外服务有很多场景都会流量增大：业务用户量不断攀升 各种促销 网络爬

背景知识：主从这个架构可以实现数据备份，数据在多个服务器上分布等等，当然最主要的优点是可以实现负载均衡，将写操作交给主节点，读操作交给从节点。 mysql官网有很多版本，例如Enterprise(企业版需要付费，当然可以试用30天)，Community(社区版，开源但是官方不提供技术支持)，当然我们常用的也是社区版，本文是基于社区版的。 mysql的安装也有源码安装和二进制免安装等等方法，本文的mysql是通过二进制免安装的方式安装的 本文使用的环境是centos架构搭建步骤如下：1.首先下

真实的支撑复杂业务场景的高并发系统架构其实是非常复杂的。比如说每秒百万并发的中间件系统、每日百亿请求的网关系统、瞬时每秒几十万请求的秒杀大促系统、支撑几亿用户的大规模高并发电商平台架构，等等。为了支撑高并发请求，在系统架构的设计时，会结合具体的业务场景和特点，设计出各种复杂的架构，这需要大量底层技术支撑，需要精妙的架构和机制设计的能力策略：1，负载均衡    添加负载均衡层，...