- 被微博屏蔽
- #平台技术沙龙#服务之间的依赖,以及被依赖资源服务质量的不可预期,是服务稳定性的重大挑战。SLA体系,是解决这一挑战的利器。
- #平台技术沙龙#服务之间的依赖,以及依赖资源服务质量的不可预期,是服务稳定性最大的挑战。SLA
- #平台技术沙龙#服务隔离是保障问题影响不被放大的重要方式。而实际操作中要做到真正隔离,会面临很多难点。课堂上有同学提出,服务隔离与灰度发布的目标是否一致,大家各自阐述自己的看法。场外的小伙伴怎么看?
- #平台技术沙龙#服务巡检和演练也是问题预防的常用手段,及时发现服务隐患。对于系统容量方面,最好能归纳出标准的容量计算公式,并通过演练进行验证。
- #平台技术沙龙#新兵训练营第四主题平台稳定性保障体系,@liudaoru 道儒老师将它分为三个阶段:预防,发现,处理。每一阶段都有更细致的规范要求,当然这些细化的要求是见仁见智的,大家觉得哪些方面更重要一些呢
- #平台技术沙龙#对于预防方面,日志是非常重要和关键的一环,关键点:实时(有问题能快速反馈出来),覆盖度(所有关键点都能覆盖到),易获取(最好有直观的图表,任何人一眼就能看出是否正常)。
- 《微博图床架构揭秘》微博春节技术保障是一个系统工程，涉及到从基础到业务的各个层面。对于微博图床而言，架构方面的优化和提升，可以帮助我们在短期资源受限的情况下高效的实现业务目标，而长线上是用户体验的提升和成本的降低 #微博技术体系春晚保障内幕#...畅读版【http://t.cn/8F5EgNh】展开全文
- 《微博陪你过大年 —— 微博春晚保障技术内幕系列》每年的春晚对于微博来说，都是一场不亚于春运或淘宝双十一的压力考验，但2014年形式尤为严峻：微博与央视春晚达成了合作，一方面流量压力更大，另一方面，保障目标级别更高了。#微博技术体系春晚保障内幕#...畅读版【http://t.cn/8F5RXmx】展开全文
- #平台技术开放日# 第十一期，@唐福林 在介绍 基于Arduino/Zigbee的传感器PAGE展示。真实的使用场景有很多，比如可以把传感器放到小孩口袋里，大人可以随时给传感器发信息，传感器会把小孩当前位置发回来；比如可以放在会场的入口，来统计参加会议的人数等等
- 面对海量小文件的存储和检索，Google发表了GFS，淘宝开源了TFS，而Facebook又是如何应对千亿级别的图片存储、每秒百万级别的图片查询？ Finding a needle in Haystack: Facebook’s photo storage 🔗 网页链接 (via @fishermen) 展开全文
- 架构的选择始终伴随着每个开发者，对于Pinterest也是如此。从只有一台web engine和一台Mysql DB扩展到如今180台Web Engine、240台API Engine、88台Mysql DBs+1台Slave Each、110台Redis、200台Memcache，读一读Pinterest的架构演变的故事，你能得到什么启示？http://t.cn/zTf5odB。展开全文
- （接上三）在#平台交流日#第1期，曾经热烈讨论cache冗余度的问题，尽管这个问题没有标准答案。我们再来参看facebook的另一McDipper思路，其目的是利用Flash存储来降低昂贵的RAM成本。试问在什么场景下，McDipper可以如文中提到节约90%的服务器？(点击大图可查看清晰版)展开全文
- 新浪首席DBA、ACE Director @jackbillow 介绍数据存储选型，怎么从性能、成本和容量综合考虑？
- #广东地震# 11:35:18 微博数据，比实际地震时间只晚了1分钟！
- Twitter最近在其官方blog中公开了技术Stack，包括一个RPC系统Finagle等，其中个还提到Ostrich、Zipkin、Mesos、Iago(load测试框架)、ZooKeeper、Scalding 和jvmgcprof。其小结时提到一个common stack好处包括任何问题在common stack中修复或提升后，使用方都可以收益展开全文
- 做题第三天, 让我们看看Facebook 2013编程挑战赛的题目，🔗 网页链接
- #让红包飞# 新浪年会没有中奖？微博金钱豹年会还是没有中奖？没关系，@TimYang 和各位经理给大家发红包！一个 ipad mini，6个五百元大奖！中奖率高达40％！错过的同事朋友下次记得一定要跟大佬们喝到最后啊！红包迎新春，提前祝大家新春快乐！另外，微博技术团队继续招人，欢迎加入微博大家庭！展开全文
- 在日常编程中，集合的使用随处可见。Apache Commons Collections 和Guava 在标准集合API基础上提供了大量额外方法；还有一些在某些特定场景下提供性能高效的集合类，如Trove、Huge Collections、fastutil、Javolution等；如何选择？你的选择是否能够达到最好的性能？推荐参考：🔗 网页链接展开全文
- 在无线开发领域，受限于移动网络延迟高、稳定性差等因素，为有线传输设计的TCP协议暴露出诸多不适。TCP Fast Open（TFO）通过Client端保留TFO cookie的方式得以在三次握手最终ACK发送前传输数据，省去了一个RTT开销，将传输时延平均降低10%，目前Redhat 3.6中已经可以支持TFO。🔗 网页链接展开全文
- log4j应用存在如下问题：1）log4j为保证线程安全大量引入synchronized锁，在高并发时引起多线程争用，影响吞吐量；2）在rootLogger和appender两个地方都存在锁，容易造成死锁；3）运行时动态配置log4j不易；视频巨头Netflix近日开源了其Blitz4j ，很好解决了上述问题。http://t.cn/zjMxUzk，性能比较：展开全文
