Feiex

Feiex

V2EX 第 537455 号会员,加入于 2021-03-14 03:41:38 +08:00
今日活跃度排名 13115
根据 Feiex 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
Feiex 最近回复了
在#85 楼的基础上补充一下,
1. 不管是 log4j2 还是 logback ,在生产环境都会有一些坑(比如打 error 日志把 CPU 打满的),这时候没必要每个团队都去写 error 限流代码,让 Util 团队升级即可
2. 很多时候实体和异常的日志序列化并不尽如人意(例如三方包的实体 toString 缺很多东西、toJson 性能又很差),这时候也需要 Util 出手统一解决
3. 最重要的还有 trace 、channel 、position 、region 等等这种链路上下文的参数打印,每个人写一遍 format 也是没必要的,需要 Util 出手统一处理
123 天前
回复了 qee 创建的主题 职场话题 钓鱼, hr 视角下这两年招聘是什么情况
小红书上有很多 HR ,最近看到一个 HR 在京东受不了压力离职了(脏活多,两头难做人),连赔偿都等不了。。。
公司网络屏蔽了各种云盘。。。
阿里国际是 lazada 吗
@roundgis 5.4 。不过 6.0 也可以
@iamtuzi3333 #2 建议重新设计 hash 并做好数据平均分布,mango 天生是玩分片的,不要玩成单机模式。
另外 mongo 有索引,hash 设计合理的话,不用太担心查询压力(可以不停机扩容)。
这个是我做过的项目,用 mongo 解决 B 端消息暂存的问题,可以参考下: https://mp.weixin.qq.com/s/wSzu1_TM4Kark5ZfEs0EvA
我曾经做过几 T 的 mongo 数据存储,每日增删 2 亿条数据。
mongo 是分布式数据库(而且可以不停机扩分片),你只要 hash 设计合理,数据节点的压力不要太大,完全能应付这个量级。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1617 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 10ms · UTC 16:39 · PVG 00:39 · LAX 08:39 · JFK 11:39
Developed with CodeLauncher
♥ Do have faith in what you're doing.