查看系统日志，显示内存不足，杀死了一个java进程，可以推测，就是tomcat惨遭了毒手，
每种数据库本身都有自身的特性,同时面临的业务不同,也会导致每种数据库需要进行调节,来满足某种业务的需求.
一条SQL语句，正常执行的时候特别快，但是有时变得特别慢，并且这样的场景很难复现，它不只随机，而且支持时间还很短。
简介 Xtrabackup是由percona开源的免费数据库热备份软件，它能对InnoDB数据库和XtraDB存储引擎数据库进行非阻塞的备份，其具备以下一些优点： 1）备份速度快，物理备份可靠
当前微信支付对整体质量要求非常高，体现在可用性方面是需要达到99.99%，同样账单平台也需要达到甚至超过该要求。但是在ES及系统环境未做优化的情况下，读写成功率是没有达到要求，在个人账单ES索引场景下，写成功率为99.85%，读成功率为99.95%，所以这里亟需优化。
不过考虑到如何安全使用 Redis 也是这个比较基础的东西，新手如果配置不当，很容易造成线上的 Redis 服务处于「裸跑」状态，被黑客恶意攻击，导致 Redis 服务不可用，进而导致依赖 Redis 服务的 Session、缓存、队列、分布式锁等业务功能瘫痪，造成严重的生产事故，所以在深入探索 Redis 底层原理和集群构建之前，学院君准备给大家插播下 Redis 的安全使用。
再JVM虚拟机中，当创建的对象的数量很多时，Eden 和 Survior1 区域会很快的满溢，就需要进行频繁地 Minor GC，这样会导致有一些生命周期较短的对象迅速长到15岁并放入到老年代中，导致老年代中存放大量的短生命周期的对象(正常请况下，老年代应该存放的是数量比较少并且会长期使用的对象，比如数据库连接池)，当老年代满溢后，会进行Full GC，Full GC是开启一个很消耗性能和时间的线程，而且不管 Minor GC 还是 Full GC 都会导致 JVM 的工作线程停止，因为 Scala 也是基于 JVM 的编程语言，所以运行 Spark 程序和运行 Java 程序在 JVM 中的内存分配情况是相同的。
redis是nosql(也是个巨大的map) 单线程，但是可处理1秒10w的并发（数据都在内存中）
当前微信支付对整体质量要求非常高，体现在可用性方面是需要达到 99.99%，同样账单平台也需要达到甚至超过该要求。但是在 ES 及系统环境未做优化的情况下，读写成功率是没有达到要求，在个人账单 ES 索引场景下，写成功率为 99.85%，读成功率为 99.95%，所以这里亟需优化。
作者：empeliu，腾讯 TEG 后台开发工程师 ElasticSearch 是一个分布式的开源搜索和分析引擎，因其功能强大、简单易用而被应用到很多业务场景。在生产环境使用 ES 时，如果未进行优化则服务的稳定性可能得不到保障，目前我们使用 ES 作为账单平台的基础组件为微信支付提供服务时就遇到这种问题。本文即从当前的业务场景出发，分析 ES 稳定性未到达要求的原因并提供相应的解决思路。 一、背景 微信支付的账单系统是方便用户获取交易记录，针对不同的用户群，账单也分为三类： 个人账单：针对普通用户群，这
升级core-2过程中,高风险节点core-5(内存水位解决临界值)发生宕机，造成业务写入抛错， core-5宕机恢复流程完成，hbase服务恢复，Flink任务Failover后自动消费积压的kafka数据。
能坚持别人不能坚持的，才能拥有别人不能拥有的。
这开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内，可以解决你的问题。加群请微信联系 liuaustin3 ，（共2150人左右 1 + 2 + 3 + 4 +5）新入群的将默认分配达到5群）,另欢迎 OpenGauss 的技术人员加入。
Redis是基于内存存储，常用于数据的缓存，所以Redis提供了对键的过期时间的设置，实现了几种淘汰机制便于适应各种场景。
大家好，我是捡田螺的小男孩。有位朋友工作三年，去面试，给大家整理一下面试题，并附上答案。
前阵子处理这样一个案例，某客户的实例 mysqld 进程内存经常持续增加导致最终被 OOM killer。作为 DBA 肯定想知道有哪些原因可能会导致 OOM（内存溢出）。
前几天在群里有个朋友问到max_allowed_packet被自动重置的问题，于是打算写个文章来描述下，因为遇到这个问题的人不少，但是提到的解决方案几乎没有。
消息队列是在乐视这边非常普遍使用的技术。在我们部门内部，不同的项目使用的消息队列实现也不一样。下面是支付系统的流转图(部门兄弟画的，借用一下): 从图中可以看到，里面用到了kafka消息队列。作用
es的搜索引擎严重依赖于底层的filesystem cache，如果给filesystem cache更多的内存，尽量让内存可以容纳所有的indx segment file索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。
每种数据库都有自己的管理内存的方法，MYSQL 管理内存（仅仅讨论 INNODB 数据库引擎）的方法大部分都关注在 innodb_buffer_pool_size 这个设置。MYSQL 本身内存管理有这么简单吗？
InnoDB引擎在处理更新语句时，会先写入redo log（重做日志），然后更新内存，最后将内存中的数据写入磁盘。在这个过程中，内存数据页和磁盘数据页可能会不一致，这种不一致的内存页被称为“脏页”。
0：日志每秒刷新，但是在事务提交时不做任何处理，1，每次提交都刷新，这是最安全的也是默认的。2，每次事务提交都把日志缓存写到日志文件，再由innodb每秒做一次刷新。
上篇文章说了，show warning可以看到mysql优化器的结果，执行计划的详解，select type的种类，有派生，物化，子查询，连接查询等。
雪花算法是 twitter 开源的分布式 id 生成算法，采用 Scala 语言实现，是把一个 64 位的 long 型的 id，1 个 bit 是不用的，用其中的 41 bit 作为毫秒数，用 10 bit 作为工作机器 id，12 bit 作为序列号。雪花算法SnowFlake生成唯一ID
项目中使用的是mongodb数据库，在测试数据入库的时候，会根据源数据，然后生成一个自增的id到数据库里面，然后线上和测试环境针对同一条数据的id是不一致的。某些数据又只有id与线上匹配上的时候，才能关联上更多的数据，因此，我会去写一个脚本将同一条数据，将测试环境的id改成和线上的一致。但可能由于脚本写的还不够完善，导致数据库里面可能会写入一些重复id的记录进去，然后id又没有加唯一索引。有重复的数据又会导致正常执行etl任务会报错，因此，需要查询出在mongodb里面某个字段重复的记录。
考的是数组+和array_merge的区别 当下标为数值时，array_merge()不会覆盖掉原来的值，但array＋array合并数组则会把最先出现的值作为最终结果返回，而把后面的数组拥有相同键名的那些值“抛弃”掉（不是覆盖）. 当下标为字符时，array＋array仍然把最先出现的值作为最终结果返回，而把后面的数组拥有相同键名的那些值“抛弃”掉，但array_merge()此时会覆盖掉前面相同键名的值.
在linux操作系统中，写操作是异步的，即写操作返回的时候数据并没有真正写到磁盘上，而是先写到了系统cache里，随后由pdflush内核线程将系统中的脏页写到磁盘上，在下面几种情况下：
mysql缓存机制就是缓存sql 文本及缓存结果，用KV形式保存再服务器内存中，如果运行相同的sql,服务器直接从缓存中去获取结果，不需要在再去解析、优化、执行sql。 如果这个表修改了，那么使用这个表中的所有缓存将不再有效，查询缓存值得相关条目将被清空。表中得任何改变是值表中任何数据或者是结构的改变，包括insert,update,delete,truncate,alter table,drop table或者是drop database 包括那些映射到改变了的表的使用merge表的查询，显然，者对于频繁更新的表，查询缓存不合适，对于一些不变的数据且有大量相同sql查询的表，查询缓存会节省很大的性能。
当内存数据页跟磁盘数据页内容不一致的时候，我们称这个内存页为“脏页”。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页”。
Redis是key-value数据库，在程序中可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了以后，Redis是如何处理的。
面试指南系列，很多情况下不会去深挖细节，是小六六以被面试者的角色去回顾知识的一种方式，所以我默认大部分的东西，作为面试官的你，肯定是懂的。
最近博主也是历尽千辛万苦换了份工作，每次换之前不找点面试题看似乎就没自信一样。。奈何网上有些面试题是比较老套的，所以这里重新总结一份2020年的，题目是有些是博主自己不熟悉的点，有些是boss直聘论坛找到的，有的是朋友的面试经历，仅作为记录。
作者 ｜ Michael Knyszek 译者 ｜ 明知山 策划 ｜ Tina 自 2018 年以来，Go GC，以及更广泛的 Go 运行时，一直在稳步改进。近日，Go 社区总结了 4 年来 Go 运行时的一些重要变化。 这些重要变化主要是： sync.Pool 是一种 GC 感知的重用内存的工具，具有较低的延迟影响，并且能够比之前更有效地回收内存。（Go 1.13） Go 运行时能够更主动地将不需要的内存返回给操作系统，减少了内存消耗和出现内存不足的可能性。这将减少最高 20% 的空闲内存消耗。（Go 1
1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了 2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的） 3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的key给干掉啊 4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适） 5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key 6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除
MySQL理论上使用的内存 = 全局共享内存 + max_connections×线程独享内存。
当应用程序访问数据时， MySQL 将数据从磁盘读取到内存，或将内存数据写入磁盘是数据库系统常见的IO操作。相比内存操作，磁盘IO操作运行速度相对较慢，需消耗较多的时间。当出现大规模数据读取 比如全表扫描，频繁数据读写请求时，高并发的写入更新数据，IO操作可能成为系统瓶颈。
内存 是操作系统非常重要的资源，操作系统要运行一个程序，必须先把程序代码段的指令和数据段的变量从硬盘加载到内存中，然后才能被运行。如下图所示：
有时候我们会发现系统中某个进程会突然挂掉，通过查看系统日志发现是由于 OOM机制 导致进程被杀掉。
之前只运行 NGINX 和 FBG 棋盘游戏很稳定。接着使用 配置中心+注册中心+接口网关 取代了 NGINX，也没有出现问题。后来再加上 UAA 认证授权中心，就总是出问题。启动 UAA 之后，接口网关就挂了；再启动接口网关，UAA 就挂了，不知道什么原因。
记录下第一次使用 GDB 调试 ClickHouse 源码的过程，这里仅仅是通过简单的调试过程了解 ClickHouse 内部的机制，有助于解决疑惑，代码小白，有错误见谅。
其实，redis采用的是定期删除+惰性删除策略。 为什么不用定时删除策略? 定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU
本栏目Java开发岗高频面试题主要出自以下各技术栈：Java基础知识、集合容器、并发编程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL数据库、Redis缓存、RabbitMQ消息队列、Linux操作技巧等。
高性能：从内存读取数据比从硬盘读取要快很多。如果数据库中对应的数据改变之后，同步改变缓存中相应的数据即可。
按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。:
redis是在内存中进行缓存的，我们在设置redis缓存时，可以设置下过期时间。那么在设置时间到期后redis是如何进行数据删除的。
Redis所有的键都可以设置过期属性，内部保存在过期字典中。由于进程内保存了大量的键，维护每个键精准的过期删除机制会导致消耗大量的CPU，对于单线程的Redis来说成本过高，因此Redis采用惰性删除和定时任务删除机制实现过期键的内存回收。
这些参数主要是用来调整virtual memory子系统的行为以及数据的写出（从RAM到ROM）。 这些节点（参数）的默认值和初始化的过程大部分都可以在mm/swap.c中找到。 目前，/proc/sys/vm目录下有下面这些节点：
所谓定期删除，指的是 redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。
一条SQL平时明明执行很快，但总有那么几个时刻，变得特别慢，看起来随机持续时间又短，难以复现。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
腾讯会议
