关于多数据源的那些事儿(萌新向)

关于多数据源的那些事儿(萌新向)在日常的JAVA后端开发中多数据源的应用场景并不少见,但对于刚刚接触springboot或是刚刚接触工程化开发的萌新来说却仿佛是一座不可逾越的高山,因为新手常常会局限于某些“固定的”项目配置,不知道如何配置?从哪里开始配置?以及什么能改什么不能改 这种现象在用惯了springboot便捷开发的老手中也很常见,众所周知,相比于spring的springboot简化了很多工程前置配置,虽然增加了工作效率却也使得开发人员失去了了解基础配置的机会 综上,本文主要讲解如何在springboot环境中,以一种最简单的、即起即用的、不依赖中间件和数据库切片的方式配置单一项目的多数据源 限于笔者能力有限,经验尚浅,若有描述不当之处,敬请批评指正
关于多数据源的那些事儿(萌新向)2019-06-28Agostino

造轮子1 注解管理

造轮子1 注解管理使用public @interface xxx{}可以自定义一个注解,在注解上面定义的注解叫做元注解 以下代码取自开源API文档生成项目Swagger: 在注解中也可以使用注解,我们称这些注解为元注解,上面代码中使用了一些比较常见的元注解 @Target({ElementType.TYPE})用于定义注解的使用范围,常见的包含 TYPE:类、接口、枚举 FIELD:字段声明 METHOD:方法声明 PARAMTER:参数声明 CONSTRUACTOR:构造函数声明 LOCAL_VARIABLE:局部变量声明 ANNOTATION_TYPE:其他注解声明 PACKAGE:包声明(代码中的第一行 声明package的时候)
造轮子1 注解管理2019-05-25鱼鱼

ELK实战(Ⅰ) 基于ELK整合分布式业务日志

ELK实战(Ⅰ) 基于ELK整合分布式业务日志大多情况下,我们可能都习惯了使用linux指令查看日志,很多时候一句简简单单的tail、grep能定位绝大多数问题 但是面临复杂的目录结构和分布式系统产生的“分布式日志文件”,如果还要我们一个一个去查日志,就会耗费很多没必要的时间 可以利用ELK这套组件快速搭建一个日志系统 注意此文仅针对可能很多情况下格式不确定的业务日志,对于某些组件日志我们有更好的可视化实践方式,可以参考此系列的其他文章 对于一个日志系统,我们要确认我们的诉求,在不同的场景下采用不同的收集方式: 是否是分布式系统需要合并多个节点的日志 如果需要,则需要用分布式组件收集并合并日志,这也是一个日志系统最基本的要求;
ELK实战(Ⅰ) 基于ELK整合分布式业务日志2020-03-14鱼鱼

Redis原理-源码解析:数据结构3 hash

Redis原理-源码解析:数据结构3 hash 所有原理实现基于Redis版本6.0.9 hash在Redis中可以认为是套了一层的string,当然,对hash来说没有数字类型 让我们依旧通过基本命令看看hash的基本数据结构实现 在set方法中我们看到了hash的初始创建过程,一个hash最开始是zipist 想要了解ziplist可以看Redis原理-源码解析:数据结构2 list ,是为节省内存而生的链表格式 所以其实在使用ziplist时其查询的时间复杂度不是遵循hash的近似O(1),而是O(n),但是在数据量不大时,这种性能的损失微乎其微,并且能预见到大多数使用hash的场景都不会存储过多的字段 所以优先使用了更节省内存空间的ziplist
Redis原理-源码解析:数据结构3 hash 2020-11-29鱼鱼

有关Session的碎碎念-ban掉cookie之后

有关Session的碎碎念-ban掉cookie之后java web中, 用session来表示用户浏览器(客户端)与服务器建立的一次会话 通常用sessionId来标记一个session,在Java中,有很简单的方式直接获取sessionId; 但是sessionId并不是session的特性,实际上,sessionId是在客户端首次创建会话时将生成的sessionId存入cookie中,在之后的访问中直接读取这个id值 当客户端禁止了cookie行为后,SessionId在每次刷新页面时都会更新,利用id来表示会话也成为了妄想,此篇文章意在说明,如何操作能使SessionId能够独立于cookie使用 这种操作其实在shiro中已经被应用了,当我们进入登录页面中,url后会出现";jssionid=xxxxxx",将sessionid显示的标注在url中,可以使用:
有关Session的碎碎念-ban掉cookie之后2019-03-08鱼鱼

算法1

算法1给定 n 个非负整数表示每个宽度为 1 的柱子的高度图,计算按此排列的柱子,下雨之后能接多少雨水 上面是由数组 [0,1,0,2,1,0,1,3,2,1,2,1] 表示的高度图,在这种情况下,可以接 6 个单位的雨水(蓝色部分表示雨水) 木板组成水桶装水,定义高度为一数组,间隔为1,求水桶最大容量如[1,5,1,2,6,3]为15,解题思路:自两边木板向中间遍历求容量,每次相对短的木板向内移动,共比较n-2次 将水灌满,求灌满后的高度,其实就是从最高点向左右两个方向向中间遍历,依次求经过的最大值,这样一来就是从最高点向两侧递减的,再减去柱子原高度即可 容易理解的想法还有按高度分层计算,但是时间复杂度过高
算法12019-03-14Sherlock

过滤器、拦截器、监听器和AOP

过滤器、拦截器、监听器和AOP用这篇文章来梳理一下这些杂七杂八的Spring MVC中的基础概念,顺便讲一下在项目中的一些基本使用和常见应用(其实主要是针对AOP的),至于使用他们实现具体的功能,后续可能会独立写出来(谁知道呢) 执行的顺序: 项目初始化:filter:init()->filter:doFilter()->preHandle->Controller->postHandle->afterComplition ->destory() 过滤器(Filter),由servlet提供,拦截URL(其实是servlet),经过代理,执行想要的方法,最基本的使用是集成Filter类并重写方法,因为是从url层面上直接拦截,可以有很多用途,比如用于用户身份校验,比如某些页面需要有用户权限才能访问,就可以利用过滤器进行拦截,一些安全框架的鉴权本身也是过滤器的实现
过滤器、拦截器、监听器和AOP2020-03-01鱼鱼

扫盲——加密那些事

扫盲——加密那些事扫盲加密解密算法 日常开发中我们经常接触MD5算法,以此进行简单的文件完整性校验或者是后台密码验证,MD5是最常见也是最简单快捷的散列算法,常用于参数或文件完整性校验,譬如网络请求发起方与接收方分别对参数做MD5编码,一旦不一致便判断请求被篡改从而拒绝该请求,从而保证信息安全,编码后的字符串是编码前文本的一个简要梗概,因此它也被称作是信息摘要算法 这个算法的特点就是不可逆,只用于信息准确性和防篡改的校验,当然,MD5作为老牌的散列算法,很多经典的编码已经可以被反向解码出来(依靠正向的暴力穷举)以及被碰撞模仿(王小云院士团队的"破解"能够根据MD5编码后串码模拟原始消息,即使它可能与原信息不同),类似的还有SHA1,因此衍生了SHA224、SHA256、SHA512等更多安全的散列算法
扫盲——加密那些事2021-05-14鱼鱼

多线程应用提高(IV) 线程安全的集合类

多线程应用提高(IV) 线程安全的集合类在Java中的数据结构一篇中,列举了Java中一些常见的集合,此文主要梳理线程安全的相关集合 我们知道,当一个实例对象只能被一个线程访问时(线程私有),无论如何都不会有线程安全的问题,但在多线程的情境下,多个线程操作同一个对象时,可能会出现更新丢失、读写数据不同步、计数击穿等现象,此时这种操作就是非线程安全的 相应地,线程安全的集合有这样的特点:在多个线程操作同一集合时,能保证每一步操作都是安全的,与串行执行的结果一致,不会出现数据不同步等预料之外的问题 可以先看这个小例子Java-lab/ListT.java at master · fishstormX/Java-lab,我在里面解释了
多线程应用提高(IV) 线程安全的集合类2019-07-13鱼鱼

阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解

阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解CAT是美团点评的一个基于Java开发的异常和性能监控项目,github地址:https://github.com/dianping/cat 本篇文章不是对CAT本身的源码拆解,而是基于本人依赖CAT client开发的代理项目进行拆解,但是并不会纰漏任何技术细节 CAT当前已有很多不同语言的Client,当然暂且是不 CAT本身是通过CAT client收集数据并上报至CAT server,server会进行并,共有六种常见数据格式:Transaction、Event、Problem、Metric、HeartBeat、调用链标记,其实如果不考虑复杂的处理(譬如Metric是可以基于指标生成折线图,Problem可以根据具体的异常类型追溯到相应的会话Track)除去Transaction剩余的数据格式都可以理解为特殊的Event
阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解2020-07-19鱼鱼

分布式系统中的一致性算法和问题解决

分布式系统中的一致性算法和问题解决在撰写脑裂问题相关的博客时发现脑裂问题的产生原因在不同算法下的分布式系统各不相同,需要先大致了解一致性算法并针对性的解决 市面上有很多开源的分布式系统,他们的数据一致性算法不尽相同,例如k-v系统的祖师爷——zookeeper采用的是ZAB的算法,而最近流行的Consul是raft算法,不同数据中心server沟通的方式则是gossip协议 不同的协议和方式对选举和数据同步有不同的处理机制,利用这篇文章来对比常见的分布式一致性算法 一个系统可能会使用多个不同的一致性算法,以便于在不同的业务环节上有着各自更贴切的处理 ps:有种观点是一致性算法不是很准确,因为replica也能保证数据某种程度上具有一致性,有人称之为共识算法
分布式系统中的一致性算法和问题解决2021-03-13鱼鱼

使用RPC与Restful接口调用服务

使用RPC与Restful接口调用服务在SOA和微服务架构中,远程通信是无法避免的,最常用的远程通信有两种方式: restful的接口,使用Http通信 使用dubbo或是Spring Cloud组件进行 RPC协议远程调用,可选地使用socket通信 不同的人对 RPC调用会有不同的看法,甚至对rpc本身的理解都不甚相同,但我认为 RPC有两种倾向: 一为语义化的 RPC 没有统一的请求规范,数据格式在开发人员中很难达成一致,在使用传统Http调用时,交互的双方需要约定一份“API文档”以保证数据格式的唯一性,这样API格式本身就成为了一道大墙,耽误研发双方的时间 但如果服务间采用语义化 RPC进行交互,双方可能并不需要一份文档,只要一份约定好的代码,并以此作为双方的依赖,在请求时也仅仅是直接调用方法本身,如此强的语义性怎能让人不爱
使用RPC与Restful接口调用服务2021-01-13鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}