Redis原理-源码解析：数据结构3 sorted set(zset))
Redis原理-源码解析：数据结构3 sorted set(zset))Redis的set数据结构在此不多讲，同Java中原理一样，set也可以理解为是hash剥离了value的数据结构，即同为dic 但是zset（有序集合）其实在底层原理上完全不同于set 所有原理实现基于Redis版本6.0.9 先看一下基本的指令实现，着重注意中文注解的地方 t_zset.c 可以看出zset的数据结构不是固定的，在其元素数或是元素的字符串过长时，其结构为zset；否则使用ziplist数据结构（像hash一样为了节省空间），二者的创建方法如下： ziplist的代码和原理可以参考我的博客Redis原理-源码解析：数据结构2 list-鱼鱼的Java小站，就是一个节省内存的压缩的链表结构
2021-02-28鱼鱼
使用RPC与Restful接口调用服务
使用RPC与Restful接口调用服务在SOA和微服务架构中，远程通信是无法避免的，最常用的远程通信有两种方式： restful的接口，使用Http通信 使用dubbo或是Spring Cloud组件进行 RPC协议远程调用，可选地使用socket通信 不同的人对 RPC调用会有不同的看法，甚至对rpc本身的理解都不甚相同，但我认为 RPC有两种倾向： 一为语义化的 RPC 没有统一的请求规范，数据格式在开发人员中很难达成一致，在使用传统Http调用时，交互的双方需要约定一份“API文档”以保证数据格式的唯一性，这样API格式本身就成为了一道大墙，耽误研发双方的时间 但如果服务间采用语义化 RPC进行交互，双方可能并不需要一份文档，只要一份约定好的代码，并以此作为双方的依赖，在请求时也仅仅是直接调用方法本身，如此强的语义性怎能让人不爱
2021-01-13鱼鱼
JVM与GC
JVM与GCJMM，长下面这个样子： 其中，堆和栈区自然不做介绍了，主要介绍： 程序计数器：线程私有的，记录正在执行的字节码地址，换言之，它告诉我们某线程执行到了那里，分支、循环等也会依赖这个来执行，这一区域不会发生OOM问题 栈：就是正常所指的栈，每个方法被执行的时候都会同时创建一个栈帧（Stack Frame ）用于存储局部变量表、操作栈、动态链接、方法出口等信息 每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程，这一区域会发生StackOverflow问题 堆：就是正常所指的堆，这里是GC的主要区域 方法区：线程私有的，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，运行时常量池也包含在里面
2019-03-28鱼鱼
[Quick Start]RedisTemplate的bean手动配置
[Quick Start]RedisTemplate的bean手动配置 有时我们可能需要手动配置Redis的连接，例如动态修改或是从特殊的参数中获取，而不是使用SpringBoot的自有配置，此篇文章意在快速指引redis的手动配置 基于Spring项目和Jedis的底层，使用RedisTemplate； 通过Maven引入相关依赖，可以的话spring-data-redis选择2.0.0以上版本，较低版本需要的依赖： 如果使用了Spring-boot并且要使用较高的版本（例如在2.1.0后才有的某些API-putIfAbsent带有超时时间的版本），我们直接修改starter的版本是不够的，二者版本并不对称，我们需要去掉其中的redis依赖并单独引入 建议保持良好的依赖管理习惯，显式的移除依赖，而不是任其覆盖，如：
2020-02-24鱼鱼
分布式系统中的一致性算法和问题解决
分布式系统中的一致性算法和问题解决在撰写脑裂问题相关的博客时发现脑裂问题的产生原因在不同算法下的分布式系统各不相同，需要先大致了解一致性算法并针对性的解决 市面上有很多开源的分布式系统，他们的数据一致性算法不尽相同，例如k-v系统的祖师爷——zookeeper采用的是ZAB的算法，而最近流行的Consul是raft算法，不同数据中心server沟通的方式则是gossip协议 不同的协议和方式对选举和数据同步有不同的处理机制，利用这篇文章来对比常见的分布式一致性算法 一个系统可能会使用多个不同的一致性算法，以便于在不同的业务环节上有着各自更贴切的处理 ps：有种观点是一致性算法不是很准确，因为replica也能保证数据某种程度上具有一致性，有人称之为共识算法
2021-03-13鱼鱼
Java的socket通信
Java的socket通信网络编程中，会使用socket通信 TCP/IP协议，即Transmission Control Protocol/Internet Protocol，传输控制协议/网际协议，他使用TCP/IP四层模型（实际开发中只涉及到四层模型，软件范畴涉及不到OSI七层参考模型）： TCP是面向连接的通信协议，通过三次握手建立连接，通讯完成时要拆除连接，由于TCP是面向连接的所以只能用于端到端的通讯 具有高度的可靠性 三次握手，即通信时，客户端和服务端共计要传输三次包，三次握手建立连接： 1.主机（客户端）发送 SYN=1（建立连接标识）和seq=x（序号），客户端进入SYN_SEND状态，等待服务端确认
2019-03-27鱼鱼
AI大模型定价对比
AI大模型定价对比https://open.bigmodel.cn/pricing 火山方舟也提供端点（GLM3 0.001） https://openai.com/ja-JP/api/pricing/ 出入价格不一样 官网和火山都有 另外有免费版本的
2024-12-18鱼鱼
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听查看源码的顺序就见仁见智了，比较普遍的做法是从IoC入手，了解容器注入的每一个环节，掌握大致的流程 由于使用的是Spring，所以在这里我们引入比较古老的xml配置文件进行bean的配置，首先定义一个bean: 配置描述bean的xml，核心只有一行： 这样一来就可以使用BeanFactory这个容器来注入bean并使用了： 本来有封装好的XmlBeanFactory，这一类现在已经被弃用了，所以采用了他的父类DefaultListableBeanFactory;当然，也可以使用更加方便和常用的ApplicationContext： 当然从xml文件读取bean的配置只是其中一种目前用的不多的加载方式，还有基于包扫描等加载bean的方法，此处仅为理解IoC的基本使用
2020-08-04鱼鱼
Java中的动态代理与静态代理
Java中的动态代理与静态代理proxy（代理）作为一种设计模式在Java中已经应用非常广泛，例如常见的拦截器是代理模式设计的，AOP是通过动态代理实现的，而基于AOP的应用就更多了，从简单的事务应用到Dubbo框架，Java开发中离不开代理，本篇文章主要阐述Java中的代理，此处是比较狭义的代理，仅指方法和类中的代理 代理模式是一种非常常见的设计模式，它通过给某对象提供代理，从而通过代理对象控制原对象的引用 以下是代理模式的简单实现： 类Admin： 对应的代理类AdminProxy： 设计良好的聚合代理模式应该是代理类与被代理类共同继承一个接口，此处只为实现功能 这样在执行new AdminProxy().changeWorld()时，除了会调用原本的new Admin().changeWorld()，在方法前后也可以做出些其他的操作
![Java中的动态代理与静态代理]()
2019-08-09鱼鱼
常见树形结构
常见树形结构树形结构 相关术语 结点(Node)：表示树中的数据元素，由数据项和数据元素之间的关系组成 在图中，共有10个结点 结点的度(Degree of Node)：结点所拥有的子树的个数，在图中，结点A的度为3 树的度(Degree of Tree)：树中各结点度的最大值 在图中，树的度为3 叶子结点(Leaf Node)：度为0的结点，也叫终端结点 在图中，结点E、F、G、H、I、J都是叶子结点 分支结点(Branch Node)：度不为0的结点，也叫非终端结点或内部结点 在图中，结点A、B、C、D是分支结点 孩子(Child)：结点子树的根 在图中，结点B、C、D是结点A的孩子
2019-03-15鱼鱼
Kafka服务端集群原理
Kafka服务端集群原理kafka是家喻户晓的消息队列，也因“纯粹”而闻名（高性能高吞吐、扩展较少较为简单），此篇文章整理Kafka的基本架构，将按照Kafka的版本迭代分别展示架构的演进（截至版本3.0） 我们在这里暂且只讨论Kafka服务端，对于生产者和消费者的逻辑简单带过 扫盲一下Kafka的部分概念： Producer mq生产者通用叫法 作为消息的生产者，在生产完消息后需要将消息投送到指定的目的地（某个topic的某个partition） Producer可以根据指定选择partition的算法或者是随机方式来选择发布消息到哪个partition； Consumer mq生产者通用叫法 消息消费者，向Kafka broker读取消息的客户端;，负责订阅和消费消息
2022-03-10鱼鱼
对多线程的执行效率探究——合理的任务并发拆分
对多线程的执行效率探究——合理的任务并发拆分通常，我们选择多线程执行任务有两个理由，一是复杂任务采用多线程处理能够在发生并发时让用户减少等待也能防止阻塞，一是充分利用空闲时间，提高任务处理的效率，就后者而言，此处探讨不考虑客户端并发是否有必要把一个任务拆分成多线程来处理 为了探究多线程的效率问题，我做了一个实验，将不同种类的任务分别用单线程和多线程执行，同时也试验了不同种类的锁机制 测试基于Java 8的版本，希望看到总结可以直接点击到文末 开启五个线程执行任务，设定了足够次数的循环输出，输出的数字和当前线程，利用System.currentTimeMillis()统计任务用时 (代码略)以下是相同任务在不同环境下执行多次的平均执行时间
2019-12-09鱼鱼
