在线甘特图|横道图|项目管理|计划管理 zz-plan
人员、任务、进度、工时、周期、依赖关系 一目了然。无论项目大小、简单复杂都能轻松管理
经济机器是怎样运行的
声明：此文为转载，非原创。
「经济机器是怎样运行的」By Ray Dalio ，含视频播放地址和详细的学习笔记。
参考笔记：【经济】📊 Ray Dalio经济原理和💹 经济周期视频笔记
.youtube_shortcodes {
position: relative;
width: 100%;
height: 0;
padding-bottom:
经济机器是怎样运行的
声明：此文为转载，非原创。
「经济机器是怎样运行的」By Ray Dalio ，含视频播放地址和详细的学习笔记。
参考笔记：【经济】📊 Ray Dalio经济原理和💹 经济周期视频笔记
.youtube_shortcodes {
position: relative;
width: 100%;
height: 0;
padding-bottom:
经济机器是怎样运行的
声明：此文为转载，非原创。
「经济机器是怎样运行的」By Ray Dalio ，含视频播放地址和详细的学习笔记。
参考笔记：【经济】📊 Ray Dalio经济原理和💹 经济周期视频笔记
.youtube_shortcodes {
position: relative;
width: 100%;
height: 0;
padding-bottom:
经济机器是怎样运行的
声明：此文为转载，非原创。
「经济机器是怎样运行的」By Ray Dalio ，含视频播放地址和详细的学习笔记。
参考笔记：【经济】📊 Ray Dalio经济原理和💹 经济周期视频笔记
.youtube_shortcodes {
position: relative;
width: 100%;
height: 0;
padding-bottom:
Redis使用规范（团队整理）
1.冷热数据分离，不要将所有数据全部都放到Redis中
虽然Redis支持持久化，但是Redis的数据存储全部都是在内存中的，成本昂贵。
建议根据业务只将高频热数据存储到Redis中【QPS大于5000】，对于低频冷数据可以使用MySQL/ElasticSearch/MongoDB等基于磁盘的存储方式，不仅节省内存成本，而且数据量小在操作时速度更快、效率更高！
2.不同的业务数据要分开存储
不要将不相关的业务数据都放到一个Redis实例中，建议新业务申请新的单独实例。因为Re
DB设计为什么建议bigint 替代timestamp?
1. 因为DATE有固定的格式，不同的地区有不同的时间表示方法，而且外国有夏令时与冬令时之分，非常麻烦
2.大多数时候我们并不关心某一个时间点，而是发生一个动作后，需要的时间，BigInt非常方便做减法而不用转化
转载请注明：刘召考的博客 » DB设计为什么建议bigint 替代timestamp?
【转】构建需求响应式亿级商品详情页
该文章是根据velocity 2015技术大会的演讲《京东网站单品页618实战》细化而来，希望对大家有用。
商品详情页是什么
商品详情页是展示商品详细信息的一个页面，承载在网站的大部分流量和订单的入口。京东商城目前有通用版、全球购、闪购、易车、惠买车、服装、拼购、今日抄底等许多套模板。各套模板的元数据是一样的，只是展示方式不一样。目前商品详情页个性化需求非常多，数据来源也是非常多的，而且许多基础服务做不了的都放我们这，因此我们需要一种架构能快速响应和优雅的解决这些需求问题。因
每周分享第 49 期
这里记录过去一周，我看到的值得分享的东西，每周五发布。
欢迎投稿，或推荐你自己的项目，请前往 GitHub 的 ruanyf/weekly 提交 issue。
（题图：千岛湖，浙江，2018）
一个美国程序员分享自己的工作方法，其中有一条是 要么不做，要做就做完。
他的意思是，不要给自己留下做了一半的活。因为这意味着你需要再回来，继续把它做完；你会挂念这件事情，它就像一个钟摆，过一段时间就会重新出现在你的脑海，时不时烦扰着你。
你的目标应该是，当
向上沟通的几个小技巧
1，沟通时机：
事前：重大决策前
事中：遇到风险（搞不定，遇大坑，延期，遇到外星人）时，及时！！！汇报。
工作中遇到风险，如：工作目标无法达成、工作会延期或者有突发情况，及时向领导汇报，注意是“及时”！
比如在你处理完突发情况时，不要以为这就结束了，你的下一步应该是立马向领导汇报当前的情况是怎么样、目前是怎么处理的，让领导了解当前的情况，知道你在处理，可以让其放下心来，树立你靠谱的形象。
永远不要给领导意外的“惊喜”，你只会被贴上“不靠谱”的标签。
事后：汇报结果，讨论
Spring 事务提交成功事件监听
现在微服务做得越来越多了，头就越来月疼了。
跨系统事务和跨系统分页是最头疼的（其实头疼也没用，解决不了的问题）
现在有这么个需求（其实同样的需求见到不少了，一直没解决）：
向数据库插入记录，并把数据发MQ给其他系统消费。
其他系统接收到消息后会调用查询接口回来查询更多信息。
可是这个时候可能插入记录的事务都还没提交，所以根本查询不到。
通常的做法是延迟消费（或者延迟发送）：
比如假设事务在几分钟内一定会提交，那就延后10分钟后再过去查询。
查询到了就可以了。