数据库Sharding-JDBC实战（二）——广播表
在我们平时的项目中，经常会有一些数据量不是特别大但是在许多地方都会用到的表，比如字典表，如果单独把这些表放在一台服务器上的话查询的话会特别麻烦，经常需要跨库操作，效率不高。 如何解决这种问题？ 我们可以把字典表在每台服务器上都对应存储一份，每台服务器上的数据保持一致，更新的时候同时更新。这种表就是我们下面要操作的广播表。
转载后端分布式锁的三种实现方式
我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的锁进行处理，并且可以完美的运行，毫无Bug！注意这是单机应用，后来业务发展，需要做集群，一个应用需要部署到几台机器上然后做负载均衡，大致如下图： 上图中变量A处在三台服务器内存中，有些情况下要想保证三台服务器的同一时刻总共只有一个线程访问变量A，也即A得作为共享变量，但A在不同的内存当中，如何保证共享？ 一个比较常见的问题是定时任务，我们经常用 @Scheduled(cron = "0 0 * * * ?")来在项目中执行定时任务在数据库进行操作，在单体项目中没有问题，但如果部署多个，那么就会造成重复，甚
数据库ShardingSphere实战之Sharding-JDBC（一）
Apache ShardingSphere是一款开源的分布式数据库中间件组成的生态圈。它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（规划中）这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。 ShardingSphere定位为关系型数据库中间件，旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。
后端springcloud学习（七）之Stream
MQ消息中间件⼴泛应⽤在应⽤解耦合、异步消息处理、流量削峰等场景中。 不同的MQ消息中间件内部机制包括使⽤⽅式都会有所不同，⽐如RabbitMQ中有Exchange（交换机/交换器）这⼀概念， kafka有Topic、 Partition分区这些概念， MQ消息中间件的差异性不利于我们上层的开发应⽤，当我们的系统希望从原有的RabbitMQ切换到Kafka时，我们会发现⽐较困难，很多要操作可能重来（因为应⽤程序和具体的某⼀款MQ消息中间件耦合在⼀起了）。 Spring Cloud Stream进⾏了很好的上层抽象，可以让我们与具体消息中间件解耦合，屏蔽掉了底层具体MQ消息中间件的细节差异，就像
后端springcloud学习（六）之Config
在单体应用架构中，我们的配置文件比如application.yml可以每次手动维护，每次修改完之后重启项目即可。但在微服务架构中可能有多个微服务，涉及到的配置文件数量较多，如果每次手动维护的话会特别麻烦。 期望效果： 基于以上诉求，我们需要对文件进行集中式管理，也即分布式配置中心的作用。 Spring Cloud Config是⼀个分布式配置管理⽅案，包含了 Server端和 Client端两个部分。
后端springcloud学习（五）之GateWay
局域⽹中就有⽹关（翻译过来就叫做GateWay）这个概念，局域⽹接收或者发送数据出去通过这个⽹关，⽐如⽤Vmware虚拟机软件搭建虚拟机集群的时候，往往我们需要选择IP段中的⼀个IP作为⽹关地址。 我们学习的GateWay（Spring Cloud GateWay），它只是众多⽹关解决⽅案中的⼀种，是微服务架构中的重要组成部分 Spring Cloud GateWay是Spring Cloud的⼀个全新项⽬，⽬标是取代Netflix Zuul，它基于 Spring5.0+SpringBoot2.0+WebFlux（基于⾼性能的Reactor模式响应式通信框架Netty，异步⾮阻塞模型）等技术开
后端springcloud学习（四）之Feign
我们之前调用远程服务的方式如下代码： 这种方式存在两个问题： 由此，Feign运用而生。
后端springcloud学习（三）之Hystrix
在微服务架构中，⼀个应⽤可能会有多个微服务组成，微服务之间的数据交互通过远程过程调⽤完成。 这就带来⼀个问题，假设微服务A调⽤微服务B和微服务C，微服务B和微服务C⼜调⽤其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调⽤响应时间过⻓或者不可⽤，对微服务A的调⽤就会占⽤越来越多的系统资源，进⽽引起系统崩溃，所谓的“雪崩效应”。 如图中所示，最下游简历微服务响应时间过⻓，⼤量请求阻塞，⼤量线程不会释放，会导致服务器资源耗尽，最终导致上游服务甚⾄整个系统瘫痪。
后端springcloud学习（二）之Ribbon
Ribbon是Netflix发布的负载均衡器。 Eureka⼀般配合Ribbon进⾏使⽤， Ribbon利⽤从Eureka中读取到服务信息，在调⽤服务提供者提供的服务时，会根据⼀定的算法进⾏负载。 Ribbon属于客户端负载均衡。 负载均衡分为客户端负载均衡和服务器端负载均衡。