@zxCoder #3

从文章里可以看到，Aurora Serverless 可以根据负载情况自动调整配置规格，最大规格可以支持到最多 6000 连接数。

如果把一个连接数看作一个并发访问，那相当于是能支撑一个「千万用户级」的系统服务。
虽然达不到 Lambda 的无限伸缩（理论上），但对于 90%（其实我想说 99%）以上的业务场景也基本够用了。

如果期望支持更大的并发，需要组合其它技术来支撑，比如说缓存、消息队列、拆分服务。

https://www.jeremydaly.com/aurora-serverless-the-good-the-bad-and-the-scalable/

Max Connections
A major limitation of relational databases in serverless architectures is the maximum number of concurrent connections allowed by the database engine. While FaaS services like Lambda may scale infinitely (in theory anyway), massive spikes in volume can quickly saturate the number of available connections to the underlying database. There are ways to manage connections in serverless environments (also see Managing MySQL at Serverless Scale), but even with Aurora Serverless, this still appears to be a possible limiting factor.

AWS uses the following formula for generating the max_connections value for Aurora instances:

log( ( <Instance Memory> * 1073741824) / 8187281408 ) * 1000 = <Default Max Connections>

A db.r4.xlarge instance with 30.5 GB of memory for example would have a default max_connections value of 2,000.

log( (30.5 * 1073741824) / 8187281408 ) * 1000 = 2000

@yidinghe #23

只是类图就错综复杂绕来绕去的……
就算代码写的再优雅，要是移交给别人（或者半年后自己再来看）会很难看懂吧……

针对这种计算规则多样，并且可能频繁修改的需求，一个比较推荐的办法是做个简单的「计算规则引擎」。

比如说：把「计算公式」和「参数」按照标准的格式记录在 Excel 文件里，「计算规则引擎」解读该 Excel 文件生成计算规则，然后应用程序读取数据并调用计算引擎作计算。
当需要更新计算规则时，业务人员只需修订 Excel，然后重新上传到系统。

除了 Excel，Python/Lua/Javascript 之类的脚本语言也能用来定义计算规则，我甚至用过 xml 。
之所以首选 Excel，是因为运营人员（产品经理、系统运维）和用户（学校老师）都熟悉 Excel 操作，而且能直接在 Excel 文件里输入一些样例数据对公式做人工验证。

@caroline1022 #22

> 我很好奇作为面试官真的有义务回答面试者反问的问题吗？

没有“义务”。但是如果追求成为负责任的面试者，很有必要。

我与候选人交流时，当对方回答问题不在点上时，即使对方不提问，也会提出一两个解决思路与他 /她作进一步的探讨。

如果候选人开始答不上来只是对问题的表述理解有偏差，这时候就可以理解问题的关注点，展现自己的技术实力；
如果候选人开始确实没有思考过这个问题，但是提示思路后能迅速理解关键点并举一反三，或者指出我思路里的不足，那也能说明他 /她的技术理解力和敏感度。

在我的招聘理念中，“面试”是一个平等交流双向选择的过程，可以认为是与未来同事提前模拟一下后面工作中的技术讨论。
我要在团队里努力营造一种“协作进取”的技术氛围，那从与团队成员的第一次接触 - 面试时就力争能给到他 /她这种印象。

@eric96

如果只评估传统的关系性数据库的话，那就尝试分区、分表、分库操作吧。

撑不住 20k tps 写入，可以考虑加一个消息队列做缓冲，批量处理批量写入。
在对读操作要求不高的场景下，问题应该不大。

> 目的：根据唯一主键从数据库中查询一行数据，要求 50TPS，延迟在 200ms

如果没有硬件资源限制的话，任何支持水平线性扩展的分布式数据库都能满足吧。
数据量再大，性能要求更高，加机器完事。

Cassandra 完美契合这一需求，参考 Discord 的经验：12 个节点，3 重复制，支撑日均过亿消息，写操作亚毫秒，读操作 5 毫秒。
https://blog.discord.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7

Discord 去年声称迁移到了性能更佳的 ScyllaDB，但是没有看到具体的性能指标。
https://www.scylladb.com/press-release/discord-chooses-scylla-core-storage-layer/

@weiwenhao #17

> 问一下大专怎么写能去大厂面试，投了几十次了都没有面试

先要明确自己的经验能力和大厂岗位要求的匹配度有多高。
以我自己为例，如果目标岗位是 Amazon Senior Principal Engineer，岗位匹配度非常低，简历写的再漂亮也没有机会。

当然了，JD 和实际要求可能会有偏差，自我评估也可能会有偏差。
一个可能的办法：寻找各种途径联系到目标大厂的资深员工（ linkedin ？微博？邮件？），请求对方帮助评估匹配度和不足之处，针对性地补强后再投简历。

@luckyrayyy #18
@jin5354 #21

> 确实没做过这么多高大上的产品就很蛋疼
> 很多候选者那简历纯 CURD

简历想要打动人，总得先要把自己的亮点找出来吧。
没有高大上的产品项目经验，可以强调对技术的钻研和应用，再退一步也能说说工作细致负责，最次那就强调努力和加班吧。
要是连努力也谈不上，那还是建议他别想着换工作了，好好修炼一两年再说。

我文中举例的测试小伙子，他的工作表现其实也就中规中矩，业界平均水平吧。但只要努力挖掘，总能找到工作的闪光点。

@Yc1992 #14

> 都 CTO 了还需要简历吗，纯属好奇

以我现在接触的层级来看，不管是猎头牵线还是朋友内推，提供一份精心制作的简历都能让对方了解你的基本情况，判断岗位匹配度，为面谈准备好讨论话题。

顶尖大厂的 CTO/VP 级别我就不清楚了，听说有些大牛是要持之以恒好几年才能挖到手的？

@dcsite #6
@ingdawn #7

> “如果把微不足道的事情都要写在简历里，那简历要多厚”
强调细节 != 微不足道，列举的数据和事实是用来佐证你与其他人不一样的成绩和特点的。

> "都这样写的话五页纸都写不下”
我自己十四年的工作经历，在两页 A4 纸里写完了。
如果能强调的经历和特点很多，那就要仔细斟酌如何取舍，看强调哪一个项目情况更能打动阅读者。
马斯克也说的是“a few”嘛，只要有一两个亮点吸引到注意，就算成功了
事实上，没必要担心过犹不及，我看过的简历，90%以上一个突出的亮点都找不到。

@forbreak #2

“略显浮夸” - 是否真的浮夸，要看下一步的面试里能否把简历里体现的亮点都表述清楚，事实充分，细节详尽。
所以我自己简历里罗列的所有内容，都预先准备好几个面试者可能会提问题的答复。
只有能经过自己反复推敲的亮点，我才敢放心写到简历上。

只要进入了面试，那就说明我们在简历这一关已经胜利了，不是吗？
至于与面试者斗智斗勇，那就是另一个大话题了。

@imes #1

“修饰词太多了” - 是有这么点儿感觉。
我习惯把简历压缩在两页纸内，为了尽可能地体现过往经历和成绩，只能省略细节增加修饰，以提高信息密度。
你有什么好建议来改善行文方式吗？

“让人觉得浮躁” - 见仁见智吧。

这份简历写的太概括平淡了，没有看到吸引人的亮点。

作为一年看了 400+简历的技术负责人，我对优秀简历的最低期望是：
描述清楚你处理过的最困难的一个问题及解决方案，带上具体的数字。

举个例子，如你的简历里加粗的“使用泛型增加并封装父类，……，大大降低了工作量，减少了重复性劳动“。
可以改写为这样的形式：
在前期项目开发中，当要增加一个新实体类型的增删改查功能时，需要手动编写 xxx 、yyy 、zzz 等 7 个类，9 个 sql 语句，20 个单元测试，普遍需要 16~30 小时开发测试，QA 测试发现 3+ bug，开发效率和质量都不够理想；
我通过分析项目代码结构和功能需求共性，将增删改查的公共部分抽象封装为带泛型的基类 AbstractEntityService，当需要新增实体接口时，只须继承该基类，将功能开发的时间缩短至 4 小时，基础增删改查功能 0 bug，大幅提高了开发效率和质量，已在全团队 N 人普及应用。

@passerbytiny

打标签和怼人并不能保护信息安全。

物理内网变成虚拟内网是支撑现在远程工作的必须，开 VPN 只是尽量为其提供一层防范。
本末倒置的话就没有讨论的价值了。

@Vamwere

有哪些企业做到了“外网部署，做好常规安全”？愿闻其详。

我以前就职的国外企业，从 2005 年前后就开始全面贯彻远程工作实践，现在整个集团有几千号人分布在世界各地。
其实践上除了 Jira、BitBucket 等有限几个工具之外，其它工具都必须通过 vpn 登录内网使用。

@Mithril

赞成“只靠技术是没用的”。

不过对于传统企业来说，“人的意识和策略”的培养需要一个漫长的过程。
而技术上的保障，效果再微弱，也是可以立杆见效的。

特别是对于行政、市场、测试等技术含量相对不高的团队和员工，一个可行的方法就是以技术倒逼策略，进而培养意识。

像这种判断条件不算太多的情况，写成 if-else 问题不大，可读性好且符合团队编码规范就行。

如果判断条件比较多（我个人习惯是 5 个及以上），可以把每个判断逻辑写成一个 lambda 函数，再循环调用它们。
```
private boolean checkMobileExists(Long shopId, CreateSupplierParam param) {
List<Supplier> supplierList = this.get(shopId, param.getContactMobile());

List<Predicate<List<Supplier>>> predicates = Arrays.asList(
CollectionUtils::isEmpty,
suppliers -> suppliers.size() == BaseConstants.INT_ONE &&
suppliers.stream().anyMatch(it -> Objects.equals(it.getId(), param.getId()))
// more predicates here
);

return predicates.stream().anyMatch(it -> it.test(supplierList));
}
```

目测贵司没有上任务管理系统
要是用了 JIRA、Trello 什么的，一个简单 filter 直接搞定任何人数任何时段内的工作动态