在线甘特图|横道图|项目管理|计划管理 zz-plan
人员、任务、进度、工时、周期、依赖关系 一目了然。无论项目大小、简单复杂都能轻松管理
MySQL分库分表解决大数据量
前段时间在WOT大会上，听了我公司（58同城）架构师的一个分享，
《大数据量下，58同城mysql实践》PPT地址：http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=204498648&idx=1&sn=849f4cafec3eb4b7fccff884bb81e8ca&scene=5#rd，颇有感触和理解。下面就根据我个人经历就MYSQL分库分表做一些简单的记录吧。
在互联网公司，大数据量
【教程】Windows配置Java环境变量
1.打开我的电脑–高级系统设置–高级–环境变量
2.新建系统变量JAVA_HOME 和CLASSPATH
变量名：JAVA_HOME
变量值：C:\Program Files\Java\jdk1.7.0
变量名：CLASSPATH
变量值：.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar;
3. 选择“系统变量”中变量名为“Path”的环境变量，双击该变量，把JDK安装路径中bin目录
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实战》细化而来，希望对大家有用。
商品详情页是什么
商品详情页是展示商品详细信息的一个页面，承载在网站的大部分流量和订单的入口。京东商城目前有通用版、全球购、闪购、易车、惠买车、服装、拼购、今日抄底等许多套模板。各套模板的元数据是一样的，只是展示方式不一样。目前商品详情页个性化需求非常多，数据来源也是非常多的，而且许多基础服务做不了的都放我们这，因此我们需要一种架构能快速响应和优雅的解决这些需求问题。因
向上沟通的几个小技巧
1，沟通时机：
事前：重大决策前
事中：遇到风险（搞不定，遇大坑，延期，遇到外星人）时，及时！！！汇报。
工作中遇到风险，如：工作目标无法达成、工作会延期或者有突发情况，及时向领导汇报，注意是“及时”！
比如在你处理完突发情况时，不要以为这就结束了，你的下一步应该是立马向领导汇报当前的情况是怎么样、目前是怎么处理的，让领导了解当前的情况，知道你在处理，可以让其放下心来，树立你靠谱的形象。
永远不要给领导意外的“惊喜”，你只会被贴上“不靠谱”的标签。
事后：汇报结果，讨论
Spring 事务提交成功事件监听
现在微服务做得越来越多了，头就越来月疼了。
跨系统事务和跨系统分页是最头疼的（其实头疼也没用，解决不了的问题）
现在有这么个需求（其实同样的需求见到不少了，一直没解决）：
向数据库插入记录，并把数据发MQ给其他系统消费。
其他系统接收到消息后会调用查询接口回来查询更多信息。
可是这个时候可能插入记录的事务都还没提交，所以根本查询不到。
通常的做法是延迟消费（或者延迟发送）：
比如假设事务在几分钟内一定会提交，那就延后10分钟后再过去查询。
查询到了就可以了。
Memcache和Redis的选型分析
Memcache和Redis都能很好的满足解决数据库表数据量极大（千万条），要求让服务器更加快速地响应用户的需求的问题，它们性能都很高，总的来说，可以把Redis理解为是对Memcache的拓展，是更加重量级的实现，提供了更多更强大的功能。具体来说：
1.性能上：
性能上都很出色，具体到细节，由于Redis只使用单核，而Memcache可以使用多核，所以平均每一个核上Redis在存储小数据时比，Memcache性能更高。
而在100k以上的数据中，Memcache性能要高于
[轉載]互联网系统架构的演进
多终端接入、开放平台给互联网带来了前所未有的用户量级和访问规模，SNS网站产生了海量的UGC（用户产生内容），而且这些内容依托关 系链扩散速度之快、传播范围之广是传统网站难以想象的，海量数据的计算存储也一直是近年互联网领域的热点。本文将从发展演进的层面探讨互联网的系统架构。
天下武功唯快不破
网站初期的架构一般采用“短平快”的架构思路，架构以简单清晰、容易开发为第一衡量指标。
互联网架构选型首先包括开发语言的选择，目前PHP、Java是主力语言。开发语言的选择一般从团队人员的
ScriptEngine解析js脚本 or 表达式
不得不说，ScriptEngine是个很强大的引擎，可以解析JS脚本，或者以JS的规则解析表达式。
javax.script，始于JDK1.6，不过现在只有sun实现的javascript的解析器，一般的用途主要是能解析通用的表达式，比如X >= 1（X作为参数传入）这样的表达式，也能利用js的函数语法，创造一个就像java的函数一样存在于内存中随时可以被调用的函数，更可以将js中的对象直接转换成java对象。
有时候出于各种原因我们需要用java模拟用户登陆一个网站，