十一年技术经验,互联网
chart 是 Helm 的应用打包格式。chart 由一系列文件组成,这些文件描述了 K8s 部署应用时所需要的资源,比如 Service、Deployment、PersistentVolumeClaim、Secret、ConfigMap 等。 chart可繁可简,即可以只用于部署一个单独的服务,例如mysql、nginx等等,也可以用于部署整个应用,例如由HTTP服务、数据库、缓存、中间件等共同构成的复杂应用。
作为开发人员大家对UUID应该都比较熟悉了,Java中也提供了相关的类和生成方法,供业务中使用。这里准备对UUID生成的过程做一次深入了解。
apache poi资料详解,包括内部jar包依赖关系,及与使用文档的对应关系
上一篇的初体验之后,本篇我们继续探索,将transformers模型导出到onnx。这里主要参考huggingface的官方文档:https://huggingface.co/docs/transformers/v4.20.1/en/serialization#exporting-a-model-to-onnx。
huggingface相关环境的安装和问题处理本篇暂不涉及,后续补充。这里以一个模型为例,完成从模型介绍到加载、运行的完整过程,作为我们熟悉huggingface的一个示例。
Java 8升级到Java高版本,网上有不少教程。但在实际的开发过程中还是会遇到一些不常见的问题。这时候就需要我们发回问题定位和搜索、分析能力了。跟以往的环境问题一样,都不是很难,但问题千奇百怪,感兴趣的话可以继续深入探究,看到底是什么原因导致了这些问题。
本篇简要介绍了MinIO的一些基础知识和操作,以及安装和使用过程中遇到的一些坑。下篇开始将深入探讨MinIO的原理和使用场景等。
抱歉也开始用了这么“标题党”的标题。事情起源于前几天需要把个人资料的pdf文档一页一页的拆出来,好传到相关的网站上。直接截图到word再转pdf比较麻烦,所以想用工具直接转换。结果找了几个pdf阅读器,这类操作都需要会员或收费。作为一名程序员,这么简单的操作还要收费显然是一种羞耻(当然我是不会承认主要是因为qiong的),几分钟就可以代码解决的问题为啥要花钱呢?废话不多说,开搞。
最近在项目中涉及到这一领域,也借着这个契机做一次对企业级业务架构设计的深入学习。
本篇将探索代码生成技术。因为业务开发中使用Java语言较多,所以这里以Java作为背景语言。
地理位置数据存储方案之redis-geo探索:基础介绍与源码解析。
这篇是几年前整理的老文章了,当时在调研流视频推送及播放相关技术,并在项目中应用,使用到ffmpeg,所以整理了这篇文章,但并未发布。最近又有相关的技术需求,所以整理出来,作为一个新的开始。
本篇分析了几个冷热分离的实现案例,并整理了一些问题和解决方案。通过mysql 和 Es的两种冷热分离实现,阐述了不同存储方案上冷热分离实现上的共同点和差别。回归本源,设计最终还是依赖于具体业务需求。后续还需要在实践中,通过足够的业务场景和数据量级支撑,来继续验证方案的可行性和潜在问题,不断进行完善升级。
关于架构,大家都有了解和理解。通常一个业务或项目,在做架构设计时,可能会包含业务架构和技术架构。其中技术架构是我们作为开发角色,在做设计时重点的工作内容。但还有架构类型的划分方式,会包括业务架构、技术架构、数据架构和应用架构四种。
最近在整理过去的项目时,回顾了某年红包活动的项目,其中涉及红包金额计算的算法。近些年各家大厂举办的春节红包活动越来越完善,关于活动背后的整体设计介绍、分析、探讨层出不穷。本篇先不关注整体架构,选择红包金额的计算方法作为分析内容。 在当时的项目中,红包金额计算主要是采用了基于一些入参的随机数生成,并且生成的是单个红包金额,并未使用队列方式做预生成。所以再次回顾这个案例,其中其实还有很多可以玩味和深入思考的地方,在这里做一次思考总结。
Redis的几种主要数据结构,大家应该都有所了解。例如最常用的五种:字符串,list,hash,set,zset。各自的适用场景也算是比较常见容易考察的内容。但再深入一点,zset底层的数据结构是什么样子的,原理是什么?跳表和平衡树的选择,为什么没有用平衡树?zset查找单一元素和范围查找的时间复杂度是多少?那么估计就有很多人无法给出准确、明确的回答了。
本文基于Redisson3.12.2版本源码,对Redisson分布式锁过程进行了分析。从获取锁、释放锁的过程,可以大概了解Redisson的主要设计思想。此外,还对基于Jedis实现的一个分布式锁示例与Redisson进行对比,来看基于Redis的分布式锁的两种不同实现方式。
在工作中,经常会看到或者用到池化技术,例如数据库连接池、线程池、内存池等等。这类池化技术在很多经典框架中都存在,并且是设计中的重要部分。
在【Mysql-InnoDB 系列】事务提交过程及系列文章中,对mysql(InnoDB引擎)的redolog、undolog、binlog及事务的提交过程有了一些介绍,本篇将尝试去实践binlog在日常操作中的查看、分析方式,以及可能遇到的问题和解决方法。
本篇从实例出发,了解Netty核心组件的概念、作用及串联过程。从概念到设计原理,再到深入了解实现细节,从而能够清晰地掌握Netty的技术细节甚至存在的问题,才能最终更好地支持我们实际的各项业务。
图片相似度计算和相似图片搜索,是图片识别领域两个常见的应用场景。例如搜索相似商品,和相似的图片,在百度、淘宝中都有应用。在某些业务中,也存在对图片相似度的计算和判断。因此,在这里简单介绍一下相关算法。
短网址也称短链接、短链。由于短信、微博等平台,对于内容有长度限制,过长的url不适合直接在微信、短信等平台直接发送原始地址,需要缩短长度。转换后的短网址用于消息发送,也可以避免过多的无用信息影响用户体验。
K8s主要构件介绍
本篇介绍了kubernete的关键概念:pods 和 工作节点,描述了大概的架构和运行时结构。然后,基于上一篇的基础,重新使用k8s的kubectl命令部署我们自己的demo应用,并分析解决过程中遇到的问题。下一张将会进一步阐述原理,并对demo进行丰富。
前面我们介绍了dubbo的核心机制,今天将开始分析远程调用流程。毕竟,作为一个rpc框架,远程调用是理论的核心内容。通过对dubbo相关实现的探究,深入了解rpc原理及可能的问题。
在容器 & 服务:Docker 应用的 Jenkins 构建 (二)中,我们了解了在jenkins中,使用compose等工具构建发布的方法。在这里,已经初步有了一点集群的影子(备份,监控及切换),但毕竟还不是多节点同时对外提供服务,例如zuul、nginx等负载对外提供负载均衡(网关)服务,来支持后面的多应用实例共同对外提供服务。本章将会对这点进行探索。
在自学或面试dubbo时,相关的问题有很多,例如dubbo 的基本工作原理,这是使用过dubbo后应该知道的。包括dubbo的分层架构、长短链接选择、二进制协议支持;之后是使用方式(服务的注册、发现、调用方式),基础配置(超时时间、线程数),这些是最基本的。 在这些问题之后,就可以继续深入底层:关于连接方式,使用长连接还是短连接?为什么? dubbo的二进制协议支持哪些,之间有什么区别/优缺点等等,也可以考察在使用过程中遇到过哪些问题,是如何解决的。这些都需要深入理解,并且有真实、长时间使用经验。
kill :发送指定的信号到相应进程。不指定信号将发送SIGTERM(15)终止指定进程。若仍无法终止该程序可用“-KILL” 参数,其发送的信号为SIGKILL(9) ,将强制结束进程,使用ps命令或者jobs 命令可以查看进程号。root用户将影响用户的进程,非root用户只能影响自己的进程。
开发过程中,遇到的一个WEB-INF/lib无效标记的问题处理
面试时经常会被问到“CPU飙高怎么排查”,“内存泄露怎么定位解决”这类问题。本篇介绍一些常见的分析方法和工具
这次准备研究容器相关技术,并不仅仅是学习,而是基于项目的实战。而使用容器的几个典型场景之一,就是通过容器构建/部署应用服务,而这与持续继承是密切相关的。我们可以使用jenkins,也可以使用其他持续继承工具,但最终都离不开对这类工具的理解和应用。在后续的学习中,还会有很多与持续继承工具紧密关联的实践案例,也会有很多问题需要深入调研解决。
以下是在现公司,给成员做分享的资料。业务案例来自:一文教会你如何写复杂业务代码。作者:张建飞,进行了重新整理。
jenkins是常用的开源持续继承工具,现在所在的工作场景,也是使用jenkins进行基于github代码的拉取、打包、构建、部署的一系列流程,并结合了容器和函数计算实现金丝雀部署。本文先从基础的jenkins环境搭建开始。
问题发生在两年前,回顾当时,问题排查缓慢,最终还是其他同学解决了问题,主要还是因为对底层原理了解不够,另外问题分析思路也不够清晰。线上问题,尤其是涉及底层内存、共享内存、进程等等的问题,还是必须要对这些基本原理和运行机制有足够的了解,才能够快速定位并解决实际问题。
上一篇关于常驻进程/守护进程的文章,介绍了守护进程的一些基本概念,本篇将介绍工作经历中的一个真实应用场景,以及遇到的问题,和当时的解决方法。
基于前面系列文章,我们可以对Java内存模型(JMM)进行总结
在某家公司工作期间,会使用常驻进程来作为需要保活运行的机制,用以维护消费者进程。但当时对于守护进程的理解还是不够深入,所以现在再把这块做个整理,并结合当时遇到的一个问题实例进行分析。注:下面内容都针对Linux操作系统。(Mac上的launchd与systemd作用相同,而且据说systemd的很多概念来自launched)。
几个理解下面内容的关键点:cpu缓存结构、可见性、上一篇文章中的总线工作机制。通过系列的前面几篇文章,我们可以初步总结造成并发问题的原因,一是cpu本地内存(各级缓存)没有及时刷新到主存,二是指令重排序造成的执行乱序导致意料之外的结果,归根结底是对内存的使用不当导致的问题。
首先明确一点,顺序一致性内存模型是一个被理想化了的理论参考模型,提供了很强的内存可见性保证。其两大特性如下: 1)一个线程中的所有操作,必须按照程序的顺序来执行(代码编写顺序) 2)无论程序是否同步,所有线程都只能看到一个单一的操作执行顺序。每个操作都必须原子执行且立即对所有线程可见。
mac下的命令小工具。
本文起源于一个用户匹配的需求。用户的不同信息分布于两个系统,且客观上无法直接打通(不必纠结具体是什么场景,这是真实存在,且非技术上能解决的),所以就涉及到两个系统id匹配的问题。
本章详细描述了指令重排序的场景,条件,以及数据依赖、控制依赖对指令重排序的影响。总结如下: 单线程程序,对存在控制依赖的操作执行重排序,不会改变执行结果;但在多线程程序中,对存在控制依赖的操作执行重排序,可能会改变程序的执行结果!这就是多线程执行时出现并发问题的根本原因,切记。
本篇把原子操作单独拿出来详细阐述,结合前面两篇文章中的CPU多级缓存结构进行串联,加深理解。下一篇会全面研究Java的内存模型。
阿里云的函数计算——FC ,是一个事件驱动的全托管 Serverless 计算服务,开发者无需管理服务器等基础设施,只需编写代码并上传。函数计算FC 会为您准备好计算资源,并以弹性、可靠的方式运行您的代码。
最近,为了提高团队成员技术水平,考察了大家源码阅读情况。作为第一期任务,选择了spring框架,范围是spring-beans,spring-context,spring-core,以及spring-web。考核方式为:了解spring框架作用、核心概念,并选择感觉最重要的几个类进行详细阐述。
MySQL InnoDB的事务模型、锁机制等设计,都是InnoDB架构设计的一部分。要全面了解它的设计实践,就必须从头看起。只有这样,才能够弄清楚它的设计思想,理解其实现上的精妙之处。
1、那就是如果未提交的时候,redolog写满了,此时是阻塞还是覆盖呢 2、如果未提交然后写满了此时落盘了,你磁盘不是有脏数据了么,这二个问题不明白
锁定读,是相对于一致(非锁定)读来说的。 当我们在同一个事务(T1)中先读数据,然后执行插入或更新相关数据时,普通的SELECT语句并不能给予足够的保护。其他事务也可能更新或删除我们在T1事务中查询的相同行。InnoDB支持两种类型的锁定读,来提供额外的保护
提到事务,大家都有基本的了解,例如mysql的事务隔离级别包括:读未提交、读已提交、可重复读、串行化;InnoDB默认是RR(可重复读);基本的MVCC等等。但大部分人对深入一些的原理就知之甚少了。本文整理事务模型的相关内容,仅供参考。
mysql官方文档,8.0版本,InnoDB架构的深度学习