fenzlie 最近的时间轴更新 fenzlie 最近的时间轴更新 | fenzlieV2EX 第 115418 号会员，加入于 2015-05-06 09:50:37 +08:00 |
| [阿里云][组内直推][北京|杭州] 数据库领域招聘 酷工作 fenzlie 2020-01-02 08:28:42 AM 最后回复来自 fenzlie | 2 |
| [阿里][北京，杭州，深圳]招聘：数据库方向 酷工作 fenzlie 2018-01-15 16:20:55 PM 最后回复来自 fenzlie | 2 |
fenzlie 最近回复了
2020-01-02 08:28:42 +08:00 回复了 fenzlie 创建的主题 酷工作 [阿里云][组内直推][北京|杭州] 数据库领域招聘 |
@tyrantZhao 各层级都要的，看潜力
2018-01-15 16:20:55 +08:00 回复了 fenzlie 创建的主题 酷工作 [阿里][北京，杭州，深圳]招聘：数据库方向 |
@fanqianger 我们团队在全力招人。。。
2015-05-07 12:56:14 +08:00 回复了 kingname 创建的主题 问与答 如何高效阅读 Java 项目的源代码？ |
@kingname 搞明白它们都是什么目的，都有什么用途。
2015-05-07 10:07:18 +08:00 回复了 kingname 创建的主题 问与答 如何高效阅读 Java 项目的源代码？ |
可以从这个项目解决的问题入手，搞明白这是个什么项目。
也可以看设计文档，看设计的框架结构。
去看引用的JAR包有哪些，搞清楚引用的目的。
去看项目执行时里面有哪些容器，哪些线程组线程池在跑，相应跑的目的是啥。
每个容器实现类捋一遍，相应的HANDLER类实现也看一遍。
还有就是按包名去了解该项目各个包都是分管什么事情的。
从80多个类中抽出所有的接口，搞清楚所有接口的用途。
这些东西搞清楚了，这个项目你就上手了。
也可以看设计文档，看设计的框架结构。
去看引用的JAR包有哪些，搞清楚引用的目的。
去看项目执行时里面有哪些容器，哪些线程组线程池在跑，相应跑的目的是啥。
每个容器实现类捋一遍，相应的HANDLER类实现也看一遍。
还有就是按包名去了解该项目各个包都是分管什么事情的。
从80多个类中抽出所有的接口，搞清楚所有接口的用途。
这些东西搞清楚了，这个项目你就上手了。
如果你不怕其它查询请求被堵塞的话，可以用LUA脚本实现一个简易的冒排。冒200次就可以了。
2015-05-06 17:21:31 +08:00 回复了 s2555 创建的主题 问与答 自己网站的动态通过什么渠道通知自己？ |
@s2555 是的，开发一套接口而已，十分简单。
2015-05-06 17:07:08 +08:00 回复了 Navee 创建的主题 问与答 找工作一定要读"面试宝典"么? |
从面试官的角度来讲，问这些基础的面试题是全面了解你的技术能力最快捷的方式，面试中的这些细节问题没必要全都答对，这个面试宝典，你拿去问面试官，估计都会有好多答不上来。确实好多细节知识没必要完全了解。如果只是被动的等面试官问这些问题，那就是坐以待毙。
对框架的理解程度非常重要。不理解框架，只会实现接口或调用方法，这种叫做流水线工人。理解自己维护系统的框架，并在一定程度上在框架上作出贡献或升级。这种才是一般公司需要招收的工程师。做到第二点，面试时就可以主动向面试官推介自己这方面的能力。 也许他对你jdbcTemplate方法是如何调用，如何查询不感兴趣。但你告诉他你用一种方式提升了jdbcTemplate中查询语句的速度，或是发现了什么BUG，在什么样的场景下有更优秀的实现，他一定有兴趣听你讲。
对框架的理解程度非常重要。不理解框架，只会实现接口或调用方法，这种叫做流水线工人。理解自己维护系统的框架，并在一定程度上在框架上作出贡献或升级。这种才是一般公司需要招收的工程师。做到第二点，面试时就可以主动向面试官推介自己这方面的能力。 也许他对你jdbcTemplate方法是如何调用，如何查询不感兴趣。但你告诉他你用一种方式提升了jdbcTemplate中查询语句的速度，或是发现了什么BUG，在什么样的场景下有更优秀的实现，他一定有兴趣听你讲。
2015-05-06 16:41:16 +08:0 回复了 kemingcao 创建的主题 程序员 数据结构设计. 站内公告，要求统计阅读数，以及可以指定接收用户，用户量现在大约几万左右，求方案 |
如果你只需要记录站内公告数，在REDIS中记一个 statics:notification_id:readnum=0 然后有新用户访问时做个INCR就可以了。
如果你需要记录每个公告，哪些用户看了，哪些用户没看，这种信息还是存表吧，几万用户，几百公告数，存个表不过百万数据而已。加上索引主键查询妥妥够用。
如果你需要记录每个公告，哪些用户看了，哪些用户没看，这种信息还是存表吧，几万用户，几百公告数，存个表不过百万数据而已。加上索引主键查询妥妥够用。
2015-05-06 15:42:00 +08:00 回复了 whatisnew 创建的主题 Redis 请支招： redis || mysql 评论，赞，星标，这些互动数据 |
@phx13ye 倒是没有留意过专门写这种场景的书。我是这样的来的，先了解一些分布式系统的基础知识，再找一些淘宝，京东，新浪微博等相关的讲座或说明去了解下。参加一些技术分享会，理解一些分布式相关的开源项目实现，比如说ZOOKEEPER，SPARK等。主要是理解这些公司分别应对的是什么样的问题，再去比较它们之间相似系统的实现差别。当然，最好是能进入有大流量公司的研发部门，这样直接干这一行最有效。
这些问题大多是有些难度，又十分有意思，实现了又很有成就感的。比如说淘宝双11时在一个电视上实时的秒级同步显示当前各地区交易总量，交易总额。这个东西正常人都知道肯定不可能是每秒执行一个SQL去数据库里查出来的。
这些问题大多是有些难度，又十分有意思，实现了又很有成就感的。比如说淘宝双11时在一个电视上实时的秒级同步显示当前各地区交易总量，交易总额。这个东西正常人都知道肯定不可能是每秒执行一个SQL去数据库里查出来的。
2015-05-06 12:13:59 +08:00 回复了 whatisnew 创建的主题 Redis 请支招： redis || mysql 评论，赞，星标，这些互动数据 |
为了回答这个问题特意去注册了一个帐号，结果发现还得等7000秒才能回复...
首先，如果你的系统还没有一个DAL层，那么是时候去实现一个了。否则下面的内容也没必要看了。
短期解决方案，你的MYSQL使用肯定有问题，不到百万级的数据不太可能搞不定。从表结构，语句，配置，连接池等等方面入手优化。就算你的业务再复杂，应该也可以应付得来。如果实在不行，必须要用REDIS，那就自己写一个一致性HASH，REDIS设置成多节点负载。这个实现快，也十分有效果，从KEY的数量上来看，区区65万X5也不算很大。 我之前记得100万KEY在REDIS中使用的内存也不过70M这样而已，当然，这和存的VALUE也有关系。现在商用服务器随便32G 64G内存，对数据结构做一些优化，REDIS也作一些优化BLABLA，用REDIS存储完全没有压力。注意这个阶段因为是对REDIS直接当数据库用的，所以要特别注意它的数据持久化和恢复方案。
如果从预期上来看数据会随业务发展有暴发式增长的话，那就需要考虑冷热数据交替的架构，简单讲就是加缓存结构，其它分库分表之类的就不提了。 可以把上述短期解决方案中的REDIS集群直接用做缓存，不会改变的冷数据扔到MYSQL数据库中去。请求先到缓存层，取不到再到数据库去取，同时把数据放置在REDIS中。这里大概的实现可以这样做，所有在REDIS中的数据全都设置相应的过期时间，每次访问重置过期时间。在每个REDIS MASTER节点拖的SLAVE节点上作RDB，把生成的RDB文件离线定时解析，把其中过期时间小于某值的所有数据同步到MYSQL中。
终极解决方案，如果你的数据量和访问量大到没边了。以上的REDIS集群不管怎么扩容，连正常的查询修改操作也完全COVER不住时。首先要恭喜你的应用比较牛B了现在。现在要做的事情有很多，可能需要有多级缓存，CDN扩展，甚至业务上要作一些妥协等等。从框架上来讲，大概的思路就是读写分离以及深化分离。 比如说，你前两步做的REDIS集群只用作读操作了，所有写操作只记录在简要日志中。写操作的请求过程中，不在数据持久层或缓存层作修改操作。然后你有离线的系统TAIL所有写操作的简要日志，把这些操作离线同步到数据持久层和缓存层。不过这样写操作因为只是记录了日志，写操作完成后有一段时间查询请求过来时是访问不到该修改的。这段时间的长短与你的离线日志流处理系统的性能相关。
REDIS 的RDB解析可以用REDIS RDB TOOLS， 用PYTHON写的，对过期时间的处理可能需要一些自定义的修改，PYTHON新手就可以胜任。
日志流的处理可以用卡夫卡，可靠，安全，速度快。
首先，如果你的系统还没有一个DAL层，那么是时候去实现一个了。否则下面的内容也没必要看了。
短期解决方案，你的MYSQL使用肯定有问题，不到百万级的数据不太可能搞不定。从表结构，语句，配置，连接池等等方面入手优化。就算你的业务再复杂，应该也可以应付得来。如果实在不行，必须要用REDIS，那就自己写一个一致性HASH，REDIS设置成多节点负载。这个实现快，也十分有效果，从KEY的数量上来看，区区65万X5也不算很大。 我之前记得100万KEY在REDIS中使用的内存也不过70M这样而已，当然，这和存的VALUE也有关系。现在商用服务器随便32G 64G内存，对数据结构做一些优化，REDIS也作一些优化BLABLA，用REDIS存储完全没有压力。注意这个阶段因为是对REDIS直接当数据库用的，所以要特别注意它的数据持久化和恢复方案。
如果从预期上来看数据会随业务发展有暴发式增长的话，那就需要考虑冷热数据交替的架构，简单讲就是加缓存结构，其它分库分表之类的就不提了。 可以把上述短期解决方案中的REDIS集群直接用做缓存，不会改变的冷数据扔到MYSQL数据库中去。请求先到缓存层，取不到再到数据库去取，同时把数据放置在REDIS中。这里大概的实现可以这样做，所有在REDIS中的数据全都设置相应的过期时间，每次访问重置过期时间。在每个REDIS MASTER节点拖的SLAVE节点上作RDB，把生成的RDB文件离线定时解析，把其中过期时间小于某值的所有数据同步到MYSQL中。
终极解决方案，如果你的数据量和访问量大到没边了。以上的REDIS集群不管怎么扩容，连正常的查询修改操作也完全COVER不住时。首先要恭喜你的应用比较牛B了现在。现在要做的事情有很多，可能需要有多级缓存，CDN扩展，甚至业务上要作一些妥协等等。从框架上来讲，大概的思路就是读写分离以及深化分离。 比如说，你前两步做的REDIS集群只用作读操作了，所有写操作只记录在简要日志中。写操作的请求过程中，不在数据持久层或缓存层作修改操作。然后你有离线的系统TAIL所有写操作的简要日志，把这些操作离线同步到数据持久层和缓存层。不过这样写操作因为只是记录了日志，写操作完成后有一段时间查询请求过来时是访问不到该修改的。这段时间的长短与你的离线日志流处理系统的性能相关。
REDIS 的RDB解析可以用REDIS RDB TOOLS， 用PYTHON写的，对过期时间的处理可能需要一些自定义的修改，PYTHON新手就可以胜任。
日志流的处理可以用卡夫卡，可靠，安全，速度快。
Select Language