功能 | 读写分离版本 | 分库版本 |
---|---|---|
单进程无锁提升单个实例效率 | 支持 | 支持 |
支持透明的后端连接池 | 支持 | 支持 |
支持SQL读写分离 | 支持 | 不支持 |
增强SQL路由解析与注入 | 支持 | 不支持 |
支持prepare语句 | 支持 | 不支持 |
支持结果集压缩 | 支持 | 不支持 |
支持安全性管理 | 支持 | 不支持 |
支持状态监控 | 支持 | 不支持 |
支持tcp stream流式 | 支持 | 不支持 |
支持域名连接后端 | 支持 | 不支持 |
SL/TLS支持 | 支持 | 不支持 |
GR支持 | 支持 | 不支持 |
读强一致性支持(待实现) | 待实现 | 待实现 |
支持数据分库 | 不支持 | 支持 |
支持分布式事务处理 | 不支持 | 支持 |
支持insert批量操作 | 不支持 | 支持 |
支持有条件的distinct操作 | 不支持 | 支持 |
具有性能优越的结果集合并算法 | 不支持 | 支持 |
支持安全性管理 | 不支持 | 支持 |
支持状态监控 | 不支持 | 支持 |
支持tcp stream流式 | 不支持 | 支持 |
linxu 查找历史命令:使用快捷键:ctrl+r mac:control+r subtext lime mac竖排选择 鼠标左键+Option -或者鼠标中键 -增加选择:Command,减少选择:Command+Shift
strace -ttT -f -p 10091 -o xxx.log
Idea全局搜索:Command + shift + F
docker run -itd --restart=always --net=host --name="nginx"
-v /opt/nginx/logs:/var/log/nginx
-v /opt/nginx/nginx.conf:/etc/nginx/nginx.conf
docker.gf.com.cn/gf-nginx-lua
oracle DB数据访问必须添加 root@ubuntu-server-14:/home/dockerimages# cat /etc/resolv.conf nameserver 10.2.66.66 nameserver 10.35.88.77
“点”就是某个具体的技术,用来解决某个具体的问题,例如使用 JDBC 从数据库读取数据,目的是解决数据掉电丢失的问题;使用 Java 多线程,目的是为了解决大量用户并发访问的吞吐量和时延问题。掌握了技术点,就可以开始基本的业务功能开发了。
“线”就是一系列相关的技术点组成,每个技术点都是为了解决某个问题。例如: *为了完成一个用户请求,开发框架首先要有路由 router 功能,路由到具体 Controller 后,Controller 进行业务逻辑处理,处理过程中可能会使用 JDBC 来读取数据,访问 Redis 读取缓存等,这一连串的技术每个都解决了一个问题点,串起来就完成了一个业务功能的处理过程。 *为了定位一个线上 Java 服务器响应慢的问题,需要用到 tcpdump 抓包,使用 Java 工具查看 jvm 的状态,使用 mysql 命令行或者工具查看数据库状态,使用 explain 分析可疑 SQL 语句。 掌握了技术线,就可以完成某个业务功能的全流程设计和开发了。
“面”就是某一类相关技术线的综合。例如: *Java 开发是一个技术面,包括多线程、JDBC、文件读写、JVM 调优、JVM 工具等多个技术线; *高性能开发是一个技术面,包括:数据库分库分表、缓存、多线程、HTTP 优化等; *数据库维护是一个技术面,包括:数据库调优、数据库问题定位、高性能数据库表设计等; 掌握技术面,已经是某个领域的专家了,简单来说就是这个领域的问题找你都可以搞定。
“体”就是多个技术面的综合。 最常见的“体”就是架构设计,对于一个大型业务或者系统的架构师来说,需要掌握多个技术面,然后进行设计和取舍。例如,一个后台架构师需要掌握 Java 的技术面、数据库的技术面、网络的技术面等,以及业务领域知识。 架构设计是横向技术面的综合,我称之为广度技术体;还有一种纵向技术面的综合,我称之为深度技术体。例如 Java 的开发工程师,当达到技术面的水平时掌握了“多线程、JDBC、文件读写、JVM 调优、JVM 工具等”,如果需要进一步在 Java 这个领域提升技术,就需要向下了解操作系统、硬件(CPU、内存、磁盘等),从而更好的解决某些复杂的问题,例如 Disruptor 高性能并发框架的设计。掌握了技术体,就可以进行架构设计,或者成为某个领域的资深专家了,解决领域级的复杂问题。
有的问题很明显,例如线上出故障,系统性能不达标,系统性能需要达到 5W QPS;但有的问题并不那么明显,并不能一眼看出是问题在哪里,是技术问题还是管理问题。 例如我们曾遇到团队间协作开发效率很低,每次开发一个业务功能,都需要几个系统的研发人员来讨论接口协议、接口数据格式、接口安全加密、业务逻辑等,大家都不厌其烦,但好像又都必不可少,团队间为了提高效率,项目经理制定了规范、流程、模板等,但作用最终都不大。那后来是怎么解决的呢?通过引入服务中心来完成系统间同步接口调用,通过引入消息队列来完成系统间异步消息通知,系统间协作效率大大提高,以前要开会讨论几个小时的事情,现在只要明确接口传输的数据内容即可,甚至都不用开会,两个研发一讨论就差不多了。 除此以外,问题的根源往往掩盖在很多问题表象之下,如果不解决根源问题,解决一个表象问题,获得一时安宁,一段时间后又发生另外的问题,长此以往反反复复。 例如我们曾有个系统,今天交换机故障导致业务问题,明天系统 bug 导致业务问题,后天机柜断电导致业务问题,还被黑客攻击过,这些问题看起来都很独立,问题的发生也感觉都是偶然的,按照出一个问题解决一个问题的方式也没什么问题,但全年来看,业务就是出了很多问题,怎么解决?我们经过分析,发现根本原因是业务需要异地多活,而架构是双机房单中心的,我们需要做到的不是避免每个问题的发生(事实上也不可能避免),而是应该做到问题发生后能够快速处理,于是通过将架构重构为异地多活,重构完成后还是有各种偶发问题发生,但对业务的影响就很小了。 发现问题的能力主要来源于经验,包括成功的经验、踩坑的经验、参考别人的经验,因此如果要培养自己这方面的能力,多思考、多总结、多学习、多参加行业交流。
达到这个级别基本都是业界大神一般的级别,说实话我也没什么经验,只能仰慕这些大神。 例如: *当年贝索斯要求亚马逊公司内的系统都服务化,后来是哪位大神想到可以把这个能力开放出来转换为“云计算”? *阿里云王坚博士当年在众人都不看好的情况下为何坚持云计算是未来? *Google 在解决大数据问题时,如何能够提炼出三篇论文,开启了一个大数据时代?
######## golang ######## java ######## spring boot : 1.自动化问题,版本问题 Spring JPA : JPA框架中支持大数据集、事务、并发等容器级事务,这使得 JPA 超越了简单持久化框架的局限,在企业应用发挥更大的作用。
######## Spring cloud
vue react
业务稳定性 业务灾备(快速恢复) 雪崩等极端情况,提供基本服务。 新技术的应用以及老旧系统处理。 人员配置:前端,后端,测试,产品,运营等; A岗 B岗 后备人员培养
------出现问题需要解决问题,先回答三个问题: 1.需求提出者需要解决什么问题 2.你解决的是什么问题 3.有没有更加好的办法
高可用是如何实现,如何保证高可用 高性能是如何实现,瓶颈在哪里
string list hash set sortset
MVX框架模式:MVC+MVP+MVVM MVC:Model(模型)+View(视图)+controller(控制器),主要是基于分层的目的,让彼此的职责分开 MVP:是从MVC模式演变而来的,都是通过Controller/Presenter负责逻辑的处理+Model提供数据+View负责显示。在MVP中,Presenter完全把View和Model进行了分离,主要的程序逻辑在Presenter里实现 MVVM:MVVM是把MVC里的Controller和MVP里的Presenter改成了ViewModel。Model+View+ViewModel。 MVVM模式的框架有:AngularJS+Vue.js和Knockout+Ember.js后两种知名度较低以及是早起的框架模式。
安卓 IOS
【golang】 1.hashmap结构 2.def iterface 3.channel类型 <- 接收以及发送;阻塞;Range;select;timeout;ticker(定时器);close
根据垃圾回收机制的不同,java堆有可能拥有不同的结构,常见的java堆分为新生代和老年代,目前还有永久代。其中新生代存放刚创建的对象及年龄不大的对象,老年带存放着在新生代中经历过多次回收后还存在的对象。 对象晋升过程: 新生代分为eden区s0,s1区(from,to)。多数情况下对象首先分配在eden区,在一次新生代回收后,存活下来的对象存入s0或s1区。每经过一次新生代的回收,对象的年龄加1。默认情况下年龄达到15的对象将晋升至老年代。如果在第一次回收的时候,存活的对象大于s0(s1)空间,将直接晋升至老年代,如果在为对象第一次分配空间时,对象空间大于eden空间的话,对象也直接分配到老年代。 (1)堆溢出:设置-Xmx调整最大可用堆空间 (2)直接内存溢出:可能是系统内存空间不足,同时没达到参数默认的上限,没有触发GC导致OOM,解决方法是通过-XX:MaxDirectMemorySize 来限制最大内存 (3)过多线程导致OOM:由于每开启一个线程都会给这个线程分配一个栈,因此当线程数达到一定程度,系统空间不足的时候就会内存溢出,可以尝试减少堆空间,或者可以通过设置参数-Xss限制每个栈的大小。 (4)永久区溢出:系统加载的类过多,导致永久区溢出,通过-XX:MaxPermSize来设置永久区最大可用空间。 (5)GC效率低下引起的OOM:GC是内存回收的关键,回收效率低很有可能引起内存溢出,可以通过合理的分配堆(包括新生代和老年代)空间去解决。
String造成的内存泄漏 内存泄漏是指,不再使用的对象占据内存不释放,导致可用内存不断减小,最终引起内存泄漏。在Java1.6中String.subString()方法就存在这样的问题。
top iostat free
非实时按秒统计QPS cat access.log | awk -F '[' '{print $2}' | awk '{print $1}' | sort | uniq -c |sort -k1,1nr
oracle mysql mongdb PQ redis tair
二叉树,排序算法 哈希表 (左程云)算法1:实现一个特殊的栈,在实现的栈的基础功能上,再实现返回栈的最小元素的操作(要求1:pop,push,getMin 操作时间复杂度为O(1),设计的栈结构可以使用现成的栈结构)
TCP: tcp三次握手以及四次挥手,tcp黏连出现解决 UPD HTTP: http协议各个常用字段以及返回值意义 http GET POST 区别
前中后 分层架构
消息推送系统:用户中心设备列表(快队列,慢队列) 日志系统 CMS系统,日志查询; 消息的推送保证(conn与sdk保障,sdk回复,删除消息;否则一直存储,离线消息以及在线消息;消息推送列表,用户可以直接查看,所有消息。) 消息一致性保证,消息分级; 完整短信系统;防止雪崩,降级发送,容灾,异常处理,日志记录;
短信系统:选型golang redis做队列;(本地redis队列和远端redis队列做缓存)灾备考虑
读取p12文件命令 keytool -list -v -keystore etj.p12 -storepass 123456 -storetype PKCS12
Kafka是最初由Linkedin公司开发,是一个分布式、分区的、多副本的、多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/nginx日志、访问日志,消息服务等等,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 主要应用场景是:日志收集系统和消息系统。 Kafka主要设计目标如下: 1.以时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间的访问性能。 2.高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 3.支持Kafka Server间的消息分区,及分布式消费,同时保证每个partition内的消息顺序传输。 4.同时支持离线数据处理和实时数据处理。