2回答

张勤一

2019-03-29

已采纳

同学你好：

    非常感谢你的支持与建议，我对你这里的问题与疑问做出一些解释与总结。

    1. SpringCloud 微服务开发框架常用的组件并不是很多，我们在实际开发的时候也只是会用到 Eureka、Zuul、Feign 这些，对于这些组件来说，它们的实现都是非常复杂的。如果不是对 SpringCloud 做开发，能够熟练应用就足够了。

    2. 关于 Kafka，我在课程中已经提出了，当前实现的广告系统架构并不是最优的，还有可以优化的空间。而 Kafka 就是用来作为优化的核心工具。课程还在持续更新中，很快会看到 Kafka 的用途。（我在课程的问题中也有提到过。）

    3. 监听 binlog 对索引进行增删改操作：这是最快而且最好的方式。可以准确的跟你说，业界的广告系统索引数据的实现都是采用这种方式做的。毕竟 MySQL 做主从同步都是靠 Binlog 来实现的，那么，它的效率一定是非常高的。

    3. 关于全量数据写在文件中以及广告索引放在 JVM （内存的 map）中：这里是有一个误区存在的。广告系统是非常特殊的，它除了对响应速度有高要求之外，而且它的数据量是非常少的。广告系统并不是用户应用，它是一个商业应用，广告数据是广告主投放的数据。举个例子：今日头条（已经是互联网界的头部公司，中小公司的数据量更少）总的广告数据也就在几十万条左右，需要的内存空间估计在：几百 MB ~ 1GB 之间。对于这些数据量来说，放在内存中肯定是没问题的。目前，广告系统业界来说，存储广告数据最优的方式是内存，其次是 Redis。除此之外，我没有见过其他的检索存储方式了。

    4. 关于 Web 页面：这个我在考虑是否加在后期的更新中。

    关于广告系统，它是互联网开发中最核心也是最复杂的工程了，这不仅仅体现在技术上，更体现在广告思想上。如果对广告系统特别感兴趣，我推荐一本书给你：《计算广告》，这是业界写的最好的关于广告思想的书。但是，这本书的难度也非常高，祝学习愉快！

    欢迎来 QQ 群随时交流、讨论，也非常感谢同学的支持！

    

5

2

张勤一

回复

慕婉清7522044

不用客气哈。对索引的增删改其实就是映射到数据库表中的数据的增删改，是比较简单的操作。所以，这里可以不用考虑去优化。用 map 存储是非常合适的，也非常好，因为 map 的效率很高，可以近似认为无论多少数据，复杂度都是 O(1) 的。索引的检索匹配方面，目前的实现中，可以继续优化的地方并不多，但是可以考虑在匹配中文（地理位置）时，尝试使用 Trie 树或者基数树，这样可以带来一些性能的提升（但是，代码实现也比较复杂）。

2019-03-29

共2条回复

丶恶徒丶

2019-05-17

web页面个人感觉确实没用   但是这段增量数据的确实是很长  其实 像地域 关键词  这种关联的留一个就行 个人 感觉  因为这几个都是可以举一反三的东西

2

0