总摘要: 直播. 代理. 面试分享.事务方案. 秒杀方案. json动态转DTO. 打开大文件卡死. 网站被刷. 接口可用行. 排序. 数据库存钱. 线程数. 秒杀. 潜力标准分享. CPU高排查. 压测. kafka丢信息. java IO模型.
2017-11-20
- 摘要: 直播. 代理. 面试分享.
1. 我发现群里没有关于直播流，RTMP协议等资料，我想问做视频实时直播要用到哪些技术栈，给点提示我去找找就行。目前我就知道要走 RTMP协议，但是 具体Java实现方案一直未果。[小护士]
三方: 趣拍sdk
技术: webRTC
2. 反向代理就是一个负载均衡？反向代理的反向什么意思？[杭州-船长]
正向代理可以做客户端负载均衡，反向代理可以做服务端负载均衡。 正向代理是本地环境设置一个代理，例如win32 的 hosts文件代理，就是一种. 反向代理是服务器远程环境设置一个代理，例如nginx写个配置 location 一下，就是一种.一般没人说正向代理，默认说的代理就是正向代理.[广州-小护士] .
其实正向反向，就是客户端知不知道接受自己请求的是个什么玩意儿. 知道自己请求的是个代理，那就是正想代理.不知道自己请求的是个代理，以为是个服务器，那就是反向代理（这个代理会把请求转到事实服务器上）.[北京-战斗].
--- nginx 为方向代理.
3. 成都马上金融面试分享.[成都-献计献策]
- ZeroCopy 是什么？
- JVM虚拟机的垃圾回收算法
- 偏向锁 自旋锁
- 数据库同步方案 binlog
- 怎么理解原子性和可见性
- SQL 调优策略 索引相关实现和向左原则
- Kafka设计原理
- Kafka 内部 偏移量如何同步（例如A机器 offset100 B机器 95 C机器98） ISR协议？
- 服务化治理
- 如何设计高可用系统，从业务的角度出发呢，例如降级
- Java容器 如何做容错的？ 例如HashMap 或者List 容器 在删除数据的时候，如何避免出错
- 如何监控线上系统问题
--- CPU 100%
--- 内存溢出- 如何排查线上系统性能问题，MySQL 慢查询
2017-11-21
- 摘要: 事务方案. 秒杀方案.
1. **单JVM跨库的替代事务的方案, 和跨应用多JVM的替代事务方案, 有区别性的考量么?[北京-屁颠颠]
有区别.为了管理事务，实际上需要有个中心。 单JVM的情况下，虽然是多数据源，但该JVM本身肯有作为中心. 跨应用的情况下，中心的选择就比较麻烦了，一般会专门做一个中心. 所以单JVM的情况下，一些java中间件可以做，比如sharding-jdbc.
北京-屁颠颠(-) 10:26:01
怎么做中心？这个中心的作用是啥？
北京-喜(-) 10:26:23
你说的是替代。我前面说的是区别，尴尬
北京-喜(-) 10:27:08
代替方案的区别， 和他们事务本身的区别很类似, 跨应用的问题，就是失败谁感知，以及补偿到底谁来做
北京-屁颠颠(-) 10:27:47
嗯，这个知道
北京-喜(-) 10:27:51
是当前应用感知和内部做补偿。 还是上游节点
北京-屁颠颠(-) 10:28:32
跨应用比较常见，一般是mq+轮询来做
杭州-Freedom(-) 10:28:40
@北京-喜 多jvm，不能用sharding-jdbc吧，一般会采用什么方案
成都-梅小西(-) 10:28:49
喜神，多个应用下+多个db的情况下还要做中心么
北京-喜(-) 10:28:57
额外加个失败存储, 延迟队列、任务库 都可以
,如果有工作流，工作流也可以做,
强事务需要做中心
成都-梅小西(-) 10:33:01
风险大，而且性能不高
北京-喜(-) 10:38:01
一般面试能说出来有补偿，在说下方案就可以了, 稍微高端点的做法是 任务库+观察者模式
成都-梅小西(-) 10:40:28
啥叫任务库+观察者
北京-喜(-) 10:41:24
就是封装1个任务库，可以跨业务支持任务调度, 补偿本质上 就是重复性执行一个任务, 观察者模式 这个 叫 监听者吧，观察者不准确.
北京-喜(-) 10:42:51
任务库 有自身的批处理引擎，发现目标任务后，回调业务进行补偿，API是标准的和消息监听一模一样差别就是有引擎，有task 模型
北京-喜(-) 10:43:58
简单理解：就是那个扫描任务的变成线程
成都-梅小西(-) 10:44:25
补偿任务包含人工处理么
北京-屁颠颠(-) 10:44:30
有点像跑流水, 感觉
成都-梅小西(-) 10:44:35
你说的重试，是代码自动重试吧
北京-喜(-) 10:44:36
可以, 我说的是平台型的, 和跑流水那个一样，可以处理这一类, 那就是 单次任务嘛
天津-coffee(-) 10:45:24
这个引擎 你们用啥组件么？或者中间插件啥的 ？
北京-喜(-) 10:45:43
引擎是个高大上的说法
成都-勇(-) 10:45:53
补偿平常都是要自己调用，这个任务库是不是就是相关于搞一个公共的平台，按照标准来做，它自己就能调用
北京-喜(-) 10:46:13
其实就是 扫描任务、发现目标任务、查找到客户端、调用客户端、管理执行结果和任务的基础属性
深圳-平凡(389918256) 10:46:33
北京-喜(-) 10:47:01
类似, 这个带log, 带log可以做些不同的事情
天津-coffee(-) 10:47:24
这么聚合型的业务 ，我们系统也急需这样一套 东西.
北京-喜(-) 10:50:35
把平凡那个图稍微改一改 就是我说的那个,加个task scanner, 从某个存储撸目标任务出来，
比如DB、tair等， 然后执行task runner, runner内 look up client consumer , 然后 invoke consumer
深圳-平凡(-) 10:52:13
事物的中心化管理 和 去中心化管理。可以参考saga和昨天那本AKKA
北京-喜(-) 10:52:17
client 拿到任务，做与之对应的补偿事情, 中心化 的瓶颈在于中心的稳定性. 我建议还是想方案的时候，
先想中心类的，有助于提炼问题本质，全局考虑, 实操的时候，采用本地的
深圳-平凡(-) 10:54:18
@北京-喜 美团分布式事务都是基于这种中心化的吗？
北京-喜(-) 10:54:31
没有分布式事务, 有也没人用的
深圳-平凡(-) 10:56:21
比如订单域发起一个订单创建成功的事件以后，后面就不用管哪个消费者关心这个事件，以及消费者处理自身事务的情况？
北京-喜(-) 10:56:43
这个看业务
天津-coffee(-) 10:57:04
想知道一下，你们怎么管理事务的?
北京-喜(-) 10:57:14
理论上是用事件机制 + 回调 机制处理的, 图书馆还还书的例子啊, 学生去图书馆还书，管理员会先处理完学生端事情，
比如处理学生卡名下的借书记录，归还系统库存，然后就可以叫学生回去了, 然后他会给自己标记个事件在脑子里，比如
需要把书放回到书架, 这个时候他可以自己找空闲事件去做， 也可以一嗓子喊下张三(专门整理书架的人)
过来拿书, 假如张三不在，他可能会过一会在喊张三(比如5分钟之后)
成都-梅小西(-) 11:00:21
也就是说，调用另外一个服务就算失败也不影响自己的服务结果？
成都-梅小西(-) 11:00:30
只是记录下
北京-喜(-) 11:00:31
受理 + 处理模型
成都-梅小西(-) 11:00:37
然后后续重试？
北京-喜(-) 11:00:42
受理结束，就是一个阶段完毕, 处理一般是另外一个阶段，通常是2个领域的事情, 比如用户退款，需要归还库存
成都-梅小西(-) 11:01:11
那这样造成数据不一致咋办
北京-喜(-) 11:01:18
自处理啊, 比如订单端发起退款操作请求的处理，然后调用库存，库存先受理这个请求，
表示接到了, 然后库存系统会标记自己有个任务，就是归还XX库存。库存系统会自己去处理这个任务的, 自己保证结果
成都-梅小西(-) 11:02:28
所以中间这个过程是允许数据不一致是把, 比如正在处理中
北京-喜(-) 11:02:38
不是数据不一致, 是视角的问题, 你是在上帝视角上, 不是在领域视角, 专人专事
深圳-平凡(-) 11:03:48
要深刻明白这个道理就看Actor，如果是业务级的Actor那就要深入理解DDD里的各种模式之间的关系，尤其是上下文和聚合.
**<<Akka 应用模式: 分布式应用程序设计实践指南>>**
西安-大蒜(-) 11:04:15
这个做法，感觉像是排队指令下发的套路
北京-喜(-) 11:04:25
全局看的，流程设计的全是串行的, 所以前后产生很重的依赖
西安-大蒜(-) 11:05:12
允许最终一致, 客户端并不知道何时返回结果
北京-喜(-) 11:05:49
实际上物理世界是有大量的并行和异步的,银行汇款就是啊
西安-大蒜(-) 11:06:03
被调用方异步响应
北京-屁颠颠(-) 11:06:14
落实这东西成本会很高吧，boss 不会批的
北京-喜(-) 11:06:29
请求、受理、应答；处理、再应答
西安-大蒜(-) 11:07:40
@北京-喜 你这个最后一步再应答是怎么做的？
苏州-一树梨花啊(-) 11:07:46
不用框架可以自己简单的做一下
北京-喜(-) 11:07:49
看业务, 就是处理结果 如果前台需要知道的话,可以是广播啊
西安-大蒜(-) 11:08:15
是被调用方处理完后把结果存储起来，等待调用方去查找吗？
北京-喜(-) 11:08:19
也可以前台自己轮
深圳-平凡(-) 11:08:37
如果是玩Actor就用DDD+AXON。如果玩中心就用saga，华为最近开源了他们的微服务框架ServicComb，其中就实现了ServiceComb-saga
北京-喜(-) 11:08:44
进来后台不调用前台, 尽量
深圳-平凡(-) 11:09:16
不管中心还是非中心化，结合DDD的模式才是最好的落地方式.
2. 谁做秒杀的可以来讲讲么. [天津-coffee]
北京-小白杨<-> 16:38:41
请求进来分配token, token分配完再进来的数据直接丢弃
北京-漫游(-) 16:40:12
我们用redis的decr，直接扣减，返回结果小于0的就失败, 扣减成功后其实就是写订单等数据了
成都-梅小西(-) 16:43:41
秒杀的重点是怎么挡住99%的请求, 不让进入db, 前端，路由，消息等各种系统先把请求挡住,
可以学魅族商城的秒杀方案, 用redis获取token
成都-梅小西(-) 18:25:33
秒杀情况下，请不要轻易用db的锁来控制, 不然就等着dba跳楼吧
广州-香蒲(-) 18:25:44
一般认为竞争很少或者不会轻易产生竞争的时候 用乐观锁
成都-梅小西(-) 18:25:55
也不对，是有个前提条件,就是你能保证90%以上的请求不会达到db，那么剩下的你走db的锁，可以接受.
你要是不拦截，直接用db去控制，dba会杀了你
广州-小护士<-> 18:27:02
秒杀一般不是先走缓存，异步更新db么
成都-梅小西(-) 18:27:20
也可以啊。也是一种方案, 只要你别拿db去硬抗, 用缓存，用队列，用路由过滤，前端过滤等等都是方法.
<<高可用架构>>
上海-给你们(-) 20:39:49
秒杀的重点是 秒杀商品找 随机参与人。记住这个逻辑就不会错
2017-11-22
摘要: json动态转DTO. 打开大文件卡死.
1.solr的一个问题 数据采集系统给我一个json串，对应于我的solr schema，schema里面有一个是动态字段price_shopcode，意思就是每个sku在每个店铺的价格是不一样的，我在添加索引的时候，首先要把这个json串转换成自己的DTO对象，但是由于是动态字段，所以有很多的字段，5000个店铺就要5000个字段，而且只要有新店铺入住，就要改代码，麻烦问问这个应该怎么设计才好?[南京-阿辉]
北京-哇咔咔(-) 22:39:38
每个sku在每个店铺的价格不一样，但是可以都使用一个叫做price的字段存啊，为什么5000个店铺就要用5000个字段
北京-韭菜盒子(-) 22:52:47
我也遇到过这种场景,当时的做法是,尽可能的找出通用字段,会涉及到搜索排序的
北京-韭菜盒子(-) 22:53:01
其他直接在Mongo或者mysql存个json
北京-韭菜盒子(-) 22:53:08
不支持按这个字段查询排序
北京-韭菜盒子(-) 22:53:32
因为扩展字段有个弊病是,同名,但未必同类型
北京-韭菜盒子(-) 22:53:53
es不支持同名字段但是不同类型
北京-韭菜盒子(-) 22:54:07
除非强转字符串,但是强转字符串无法排序
北京-哇咔咔(-) 23:01:21
复杂的不需要计算和查询 的字段可以存json
北京-哇咔咔(-) 23:02:08
需要用来查询的可以定义属性名和属性值表，在sku保存这个sku的属性值id连接成的字符串
2. jvisualvm 这个能像java一样指定内存大小吗?我现在用这个工具打开个500M的堆直接卡死, 有什么方法能解决这个工具,打开大文件卡死问题? [北京-韭菜盒子]
北京-哇咔咔(-) 23:03:08
mat可以解决你的问题
北京-哇咔咔(-) 23:04:56
可以jhat线上的dump文件，然后用浏览器看
北京-韭菜盒子(-) 23:05:21
jmap还可以grep看
北京-韭菜盒子(-) 23:05:26
感觉比jhat方便
北京-哇咔咔(-) 23:05:47
没有图形界面，还没有oql
2017-11-23
- 摘要: 网站被刷. 接口可用行. 排序. 数据库存钱. 线程数. 秒杀. 潜力标准分享. CPU高排查.
1. 网站被刷有什么手段吗？运维封了几个百ip了[中山-划船]
珠海-阿狗(-) 8:55:07
ip限制和图形验证码，手机号频率。[极验验证]
杭州－东子(-) 8:54:48
你随意加个验证操作，破解的人，破解难度就需要成倍增加了, 你不用纠结能不能破解，你只要让自己破裂难度增大了，他就会去找破裂难度不大的网站了
2. 现在有个需求 就是某个服务有20个接口 有5个核心接口 15个非核心接口, 现在在高峰期想保证5个核心接口的可用性，访问15个非核心接口直接返回或者跳转.[北京-高天悦]
北京-高天悦(-) 9:25:05
30万用户 同时12：00 开始操作, 都写
成都-淡(-) 9:25:34
那11点50的时候申请临时服务器啊
成都-淡(-) 9:27:05
瓶颈在哪
北京-高天悦(-) 9:27:08
数据库主从非集群, 每次高峰 数据库延迟达几十秒 ,目前用redis作为分布式锁 ,某样物品 一个用户选了 另一个用户一定不能选 , 现在有redis缓存 但是mysql还是扛不住 , 一个主从库
成都-奋斗(-) 9:32:12
如果异步写库，不会存在他说的那种问题吧。
北京-高天悦(-) 9:33:04
12：00开始 放开访问, 30万用户就来抢了
成都-梅小西(-) 9:33:51
首先，我建议你分库，不要放一个库，比如订单一个库，用户一个库。然后每个库一主，2从，然后高分期，先写缓存，然后定期写db
北京-高天悦(-) 9:35:25
类似秒杀 不过比秒杀麻烦点儿, 一张表大约3000万到4000万条数据 不过热点数据会提前打入Redis
北京-高天悦(-) 9:46:15
就是现在短时间没找到原因 暂时想用人工开关降级来应对一下
北京-高天悦(-) 9:58:06
服务降级可以放在NGINX走吗
广州-小护士<-> 9:58:55
貌似要写插件
3, 饿了么、美团，那些距离排序是咋完的，而且还带分页的 ，难道是一次性全部排完？ 在按前端翻页需求加载？[上海-NICE]
北京-哇咔咔(-) 14:10:40
R 树索引
北京-哇咔咔(-) 14:11:24
或者先按geohash计算，再把符合geohash的数据按距离排序
北京-哇咔咔(-) 14:11:54
但是这个做法不够准确，不过能满足一般情况
上海-NICE(-) 14:12:20
或者先按geohash计算 ？全部计算好？
北京-哇咔咔(-) 14:12:36
保存的时候就算了geohash，并保存下来
北京-哇咔咔(-) 14:13:20
查询的时候按用户经纬度的geohash查出来，再计算符合这个geohash的所有数据的距离，缓存下来
成都-孤狼(-) 14:13:27
保存经度维度，geohash
成都-孤狼(-) 14:13:35
匹配的时候只匹配geohash
北京-哇咔咔(-) 14:13:57
geohash不能按距离排序，只能计算大致范围, 可以把geohash计算到很高的精度，这个精度控制的好也能模拟出一个大致准确的结果，然后模拟出类似按距离排序的结果, 再精确的结果就是R树索引，是在B+树的基础上对空间数据的扩展
上海-NICE(-) 14:16:21
行，我去看看
北京-哇咔咔(-) 14:20:19
R树索引有点复杂，需要精通磁盘IO和文件系统特性才能做的好
4, 对了，昨天群里讨论的钱在数据库里存什么，是什么结果？分的整数？[中山-划船]
中山-划船(-) 14:31:46
我们目前是分的整数，不过以后应该会改成 小数点 元
广州-小护士<-> 14:40:23
重点不是怎么存钱~, 重点是把钱分级
北京-漫游(-) 14:40:40
为啥要改成小数点？[整数转起来麻烦]
北京-喜(-) 14:41:04
看你把钱看成是个数字 还是个模型, 如果是模型，额度只是它的一个属性,
精度、单位等也是属性
广州-小护士<-> 14:42:25
严格来讲都是存long，最小位单位为分
北京-漫游(-) 14:43:21
电商一般都是这么做, 互金要求精度比较高, 我之前公司是存小数，不知道有没有存bigint的公司
北京-哇咔咔(-) 14:44:44
我们有些供应商要求钱精确到小数点后四位的, 所以只算到分是不行的, 存double/float也是不行的，丢精度的
5, 核心线程数 最大线程数 队列大小 跟cpu核心 有没有一个可行的公式? [杭州-所长]
杭州-所长(-) 15:21:41
我想问的是ThreadPoolExecutor 参数之间的关系, corePoolSize maximumPoolSize BlockingQueue容量关系? 比如我设想 三个参数分别是 8,16,32.
成都-勇(-) 15:23:12
http://www.infoq.com/cn/articles/Java-Thread-Pool-Performance-Tuning/
北京-coder-在线教育(673101378) 15:23:12
队列满了就用16了
6, excel导入展示在页面，只能用poi吧？[山西-小龙]
北京-coder-在线教育(-) 15:34:25
也可以用js
山西-小龙(-) 15:38:35
jxls不能实现吧？
北京-屁颠颠(-) 15:39:51
js 不行吧
北京-coder-在线教育(-) 15:40:42
我都实现过, 直接读excel文件, 没有node.js的东西，纯客户端js
7, 漫谈秒杀设计.
北京-喜(-) 16:11:42
秒杀背后的逻辑是：流量怎么抗, 有多少个抛出拒绝异常的？
北京-喜(-) 16:12:03
你1个应用 做这么多事， 你设计的再好，意义也不大, 抗流量的应用，性能一定要好
北京-屁颠颠(-) 16:12:31
一般 redis 做排队吧
北京-喜(-) 16:12:39
这就是为什么需要有很多的预热和预先分配, 不是过程中实时计算
上海-大文(-) 16:13:06
外层限流，内部做队列
北京-喜(-) 16:13:32
最后才是 库存怎么控制
北京-金木犀(-) 16:14:25
一般这种秒杀系统怎么设计，有哪些坑，可以介绍一下吗？
广州-小护士<-> 16:14:27
用token申请+校验token， 入库 - 1
北京-喜(-) 16:15:00
前面说了 2层啊, 1层是流控层 1层是交易层, 绝对不是一个应用 不是一个集群, 如果只有1个应用，挂在最前面 既抗流量又做交易, 交易做的下去么？ 流量会把资源打垮.
北京-金木犀(-) 16:18:39
其实我更想知道，抗流量如何去划分，怎么去设计能保证服务正常，然后在就是第2层的设计
北京-屁颠颠(-) 16:20:37
还没熟悉业务前，不要大动作
北京-喜(-) 16:20:52
流量怎么 和你怎么抗读流量是一样的, 只不过按照业务特点，有些会是漏斗的, 给到交易的，基本已经是目标流量了, 可以有1-2倍的buffer, 比如20个库存，放40个进来
广州-小护士<-> 16:22:52
@北京-喜 是不是先要给用户分发token？然后提交订单校验token，队列传入库存系统，库存-1，返回订单成功, 限流主要在分发token那里做
北京-喜(-) 16:23:10
目标用户才发token, 这个是安全性的要求, token发的比库存多, token发完 基本等于活动结束
北京-哇咔咔(-) 16:26:02
为什么token要比库存多，而不是一样？ [交易的成功率,留buffer]
广州-小护士<-> 16:26:08
@北京-喜 token是不是都要预先生成，然后分配到各个节点做本地缓存，用户进来其中一个节点后就去拿token？？
北京-喜(-) 16:26:17
这样最好, 提升性能
广州-小护士<-> 16:27:16
token比库存多是因为要预防有些人撤单, 撤单的人已经占用了token，称为无效token [这个是业务规则，有的秒杀必须支付]
北京-喜(-) 16:29:35
这个场景下说的队列，是营造一种库存排队的感觉出来, 如果一单只能买一个，让token跟库存一样多，发一个token，就肯定能买一个。这样不是更好, 其实是需要一定的并行处理能力的。 单MQ，consumer中需要异步处理，避免拥堵
北京-喜(-) 16:30:45
对交易流程和成功率有信心可以, 这个还要看对失败的交易的态度, 是补偿 还是 丢弃
杭州-所长(-) 16:31:22
话说rabbitMQ 如何设置并行消费?
北京-喜(-) 16:31:34
先ack
广州-小护士<-> 16:34:19
ack？握手？
北京-喜(-) 16:34:27
先 ack consume success, 给broker
上海-小安(-) 16:55:29
用户抢购的时候，会去查询库存，这时候如何保证剩余库存的实时性呢？
北京-永恒(-) 16:57:02
redis 锁
北京-喜(-) 16:57:46
1个是 不一定查的是库存， 2个是即便查的库存和实时性关系不大。 流量远超库存
上海-小安(-) 17:00:29
@北京-喜 嗯嗯，明白了，抢购的时候，流量远超库存，要库存也没啥用了
成都-梅小西(-) 17:00:36
只要保证不超卖就行了
北京-喜(-) 17:00:45
流量和库存的关系 是这样, 还有另外一层原因, 秒杀和正常售卖的入口规则不一样, 正常售卖 是 有库存才展示给用户的, 秒杀是 先开放，动态分, 是活动维度, 活动下面才是商品, 虽然用户看起来都一样 好像都是商品
上海-小安(-) 17:03:52
嗯嗯，维度确实不一样，谢谢啦，我刚才搞混啦
广州-小护士<-> 17:04:21
秒杀不展示库存吧~
北京-喜(-) 17:05:49
展示不展示 秒杀结束展示活动已结束还是售罄, 都是业务细节了, 活动已结束是活动维度 售罄是库存温度
广州-小护士<-> 17:06:37
我意思是没有实时展示库存~
北京-喜(-) 17:06:53
没有实时库存
北京-喜(-) 17:09:04
拼单没有秒杀. 这些业务 和 订单、库存系统 有关系，但是又没直接关系, 拼单、秒杀、正常售卖、各种分享赠送等都是业务[这些都可以复用交易、订单、商品、库存、价格、支付、结算/清算等系统. 我是想说这个，只有理解了这个，才会理解阿里的。 不然别人说了原因，你还是不知道]. 订单和商品系统、库存系统是下面的原子服务, 然后大家可以去理解下阿里的前中后台架构.
上海-MrString(-) 17:12:37
我有一个疑惑 为啥现在很多电商行业重心都在拼单上面呢？
西安-hopeAngel(-) 17:12:59
因为拼单可以空手套白狼
广州-小护士<-> 17:13:11
因为拼单多卖, 供应商也好做批发
北京-喜(-) 17:14:23
物流也是钱啊
8, 喜神你学业务看哪些书籍？[深圳-平凡]
北京-喜(-) 17:33:08
擦，这个我没办法. 我只能剧透1个技术团队判断具体某个同学潜力的标准
深圳-hanson(-) 17:34:37
标准 是对业务理解？
北京-喜(-) 17:34:45
不是，是聪明, 第二个标准是心态. 心态 1个是积极性 1个是心智(包容性、换位、持久性等). 聪明与否，觉得高度上限. 心态好与差，决定能不能达到这个上限. 聪明就是传统的聪明.
南宁-为两餐(-) 17:49:57
所在平台对能达到的高度有影响啊
北京-喜(-) 17:50:17
有影响 不是绝对影响, 先是人 然后才是环境 不要搞反了
南宁-为两餐(-) 17:51:09
人也是要环境中成长吧
北京-喜(-) 17:51:21
差的环境也可以啊, 这个就是心态.
北京-喜(-) 17:52:00
去哪里工作都是解决问题的. 问题是解决的什么难度的问题, 什么类型的问题. 技术同学容易 眼里只有技术问题, 认为其他的问题，都是别人的坑, 大多数思想都是事不关己 高高挂起[这是思维的局限，跟个性也有关系。甩锅是不行的], 所以会有天花板, 不管走技术路线 还是 管理路线, 后期都是要通过别人拿结果， 过程也不会一帆风顺。 需要有好心态、抗挫折，扭转局面的能力.
9, CPU高问题排查
杭州－东子(-) 21:16:48
那个线上cpu百分百我遇到过俩次
杭州－东子(-) 21:19:13
第一次估计是部署时候服务器有问题
杭州－东子(-) 21:19:31
第二次肯定有人代码有问题
北京-foryous(-) 21:19:41
我的storm集群前段时间经常cpu百分九十以上
杭州-Freedom(-) 21:19:45
我最近排了N次的CPU 100%、内存泄漏，感觉这块的技能树点了很多
杭州－东子(-) 21:23:43
Kafka 内部 偏移量如何同步（例如A机器 offset100 B机器 95 C机器98） ISR协议？
杭州-Freedom(-) 21:21:36
@杭州-emoji 群里的java问题排查手册，是神作, 另外，谷歌下 java cpu 100%、内存泄漏，看看相关文章、经验、思路. 另外，推荐你假笨的微信公众号，也有相关文章分享.
北京-foryous(-) 21:27:31
我遇到cpu很高的时候，内存也使用很高，机器负载高，然后一直在fullgc
中山-划船(-) 21:29:55
cpu100% 就多jstack几次，看看跑的哪行代码，基本就O了
杭州-Freedom(-) 21:36:23
如何定位消耗CPU最多的线程
2017-11-24
- 摘要: 压测. kafka丢信息. java IO模型.
1, 最近搞压测，被压方法调用一次rpc方法，读一次数据库，写入一次数据库（mysql innodb RR），我跟踪了每个步骤的耗时，凡是单次操作超过100ms的都打印log，后来发现这些打印的log中rpc耗时最迟的可以达到200+ms，数据库读取最迟可达到1000ms，写入操作最迟可以达到500ms，出现这种情况首先联想到的是连接池不够用，所以rpc和数据库的连接池连接数都适当调大，可是qps并没有提升，打印出来的log也没有下降。。还有什么其他原因吗？网络抖动？[上海-大文]
上海-大文(-) 10:52:05
①进入程序-------->②查询数据库------->③调用rpc------->④写入数据库
以上正常情况下都可以在50ms甚至30ms内完成，但是qps一直上不去，所以就打了log查看，把单次调用超过100ms的打印出来，发现在②③④处均有延迟的情况
北京-EP查水表(-) 10:53:35
你qps多少啊？有多少个服务线程？
上海-大文(-) 10:53:59
开了70个线程循环调用, qps测出来在500～700左右
北京-EP查水表(-) 10:56:04
没明白……，其实你qps的话，用 1000/平均响应时间 * 线程数，大致就能算出来啊, 或者反推响应时间，看是否符合预期, 不是看你几个线程调用，是看服务端几个线程在服务啊
北京-喜(-) 10:56:35
2的话 可能是慢查询引起的，需要查看DB整体负载情况、数据量、引擎、索引等。3的话，需要对下游调用加超时控制和对应的兜底处理, 4同2.
上海-coty(-) 10:57:00
cpu没上去可以继续加线程啊
上海-大文(-) 10:57:41
CPU占用率比较低
北京-EP查水表(-) 10:58:31
压测还有一种典型结果就是，客户端机负载满了，然后说服务端的压测结果不理想
上海-大文(-) 10:59:09
我是本地自测接口, rpc和数据库都是远程服务
上海-大文(-) 11:01:18
@北京-喜 应该不是慢查询，就一个id查询
北京-喜(-) 11:01:54
是个分段的事情, 你1个段1个段去分析 优化, 优化完一个点，重新再压，观察效果提升度, 然后重复上面的过程
上海-大文(-) 11:03:09
连接池问题我调大了，没有明显提升
成都-梅小西(-) 11:04:17
你这压测有很多insert？
上海-大文(-) 11:04:36
一个，最后一步会进行, 但是并发量很大, 可能会影响其他线程
北京-EP查水表(-) 11:04:51
1000/50*70=1400，囧 50ms时间算出来的一点都不靠谱，偏差那么大，一点都不靠谱
成都-梅小西(-) 11:05:23
insert确实对压测有影响吧。并发insert，而且是一个表，如果索引太多，确实影响不小
武汉-java(-) 11:06:21
把索引都去掉 只留主键 , 反正你都是根据id查询的
上海-大文(-) 11:06:28
rpc的调用为什么也这么慢？正常8ms就响应的慢的时候会拖成几百ms, 这个可以试试
成都-梅小西(-) 11:07:15
insert会根据索引锁行
上海-中纪委(-) 11:10:06
有沒有insert前刪除索引，insert後再重新建索引?
广州-Ryan(-) 11:11:09
你们这个调优完全靠猜啊。。。
看一下指标再下手，比如连接池，不够，可以看看历史连接池数量。
执行SQL，可以看看连接db的速度，和执行的速度（不过这个要在客户端统计。）
武汉-java(-) 11:12:33
看监控 和db日志 。
2. Kafka在极端情况下会丢消息；我司CTO说Kafka是工业级的，不会丢消息，丢消息是因为误用了。那么，Kafka到底会不会丢消息？[杭州-Freedom]
北京-Easy哥(-) 14:44:48
kafka不丢消息 需要几个条件 第一 至少异地机房 第2 写操作 至少要写2个副本成功 第3 这2个机房不能是同一网络供应商 ,第4 这2个要写的副本 必须分布异地机房 ,能做到 不丢 , 剩下的都是扯. 你只有一个机房 google的人来了 也不敢跟你说 不丢.
南京-Tracy(-) 14:46:01
异地机房，kafka是怎么支持的啊？
南京-Tracy(-) 14:46:22
节点分开放到2个机房？
天朝-秋天(-) 14:46:39
第3 这2个机房不能是同一网络供应商 , 这个是为啥呢
北京-Easy哥(-) 14:46:59
还有好多人 用kafka 的写策略 是只写主 不丢才怪
深圳-hxj(-) 14:49:24
同一网络供应商怕一个网络异常, 我们就出现过一次，都是一个供应商的
3, java IO模型的同步异步 阻塞非阻塞真的是好绕啊, 看了那么多 感觉每个人讲的都是自己的逻辑.有没有大神总结过这个？[深圳-鲶鱼]
广州-小护士<-> 16:59:30
同步异步是程序执行顺序
阻塞非阻塞是程序执行等待不等待
同步保证执行顺序，异步不保证
