最好是将项目经历,在项目中遇到的问题,遇到的坑,怎么解决的;让个人成长最快的一些案例;要有实际的落地的东西,能讲出来这些很细节的东西。

@scholers 感谢分享。

那我转行了 (;′⌒`)

@caojiantao 加油,朋友

加油. 重要是要有自己的思考

我也很想在工作有跟多的自己的思考,但是实际工作中很难是这样的,会很多很多各种问题,而且现在的社会每个人压力都这么大,烦躁的事情各种各样,,,,,,,,,,,,,

楼主的问题给了我当头一棒,提出的问题大部分都回答不了 继续努力!

没有经历过从小项目到大项目的整个过程,可能真的很难回答上面的问题

@shanliangxiaomifeng 确实如此,很多时候需要经过大项目的实践,对问题和知识点才会有更深刻的理解。

看过和用过是两回事,仅仅是看过深入问下去必然暴露。

一定要有自己的思考,解决问题的思路。

哪有那么多机会给人去历练,
多少人都是运气好站在了时代的浪潮之巅,你并不比别人聪明多少,你只是机会好
其他剩下90%的人还不是只能靠10%的那些人总结的经验来背诵面试题

能答上来起码看过了......起码看过了有了基础你才知道怎么去思考,要是没看过连思考的方向都没有..所以我觉得掌握这些理论知识还是很有必要啊,理论做基础,实践中求证,进步才快.事实上如果不看这些东西工作中大部分知识你都了解不到啊..起码对我一个初级研发人员来说是这样

对于分库分表,我有一个疑问,就是分表的逻辑还是最终需要根据业务去考虑吧?

文档中按照订单id去取模分表,那么如果一个人的历史订单列表怎么办?从多个库多个表取?然后合并?
如何做分页?

消息的顺序消费根据key存在不同的内存队列里面 , 服务挂了是不是就丢了 ? 用redis 做持久化可行吗?

类似布隆过滤器

希望有人来回答,这是一个非常非常"重要"的问题。!!!!!!!!!!!!!!

 1、上述说了,使用多线程,多线程,线程多了,你服务器cpu核心能跟上吗?
 2、且为何一定要用多线程,分区可以设置大一点,直接设置9,消费者配置文件直接配置并发数9,和第一点效果还快一些。也能保证顺序!第一点出现的原因是因为

partition数量不宜过多吗,如果是那么能理解。

 所以,为什么一定要用多线程。还要用阻塞队列。直接配9个消费者不更好吗?既然配置3个改一下不就可以了吗?

拜托了,有人来说明下吗,"我非常非常感谢"

分区多副本 创建topic时设置"replication.factor"设置分区副本;这样这样当一个节点挂掉Isr会选举新leader提供数据,除非三台全挂 /opt/kafka_2.13-2.8.1/bin # kafka-topics.sh --describe --zookeeper 172.18.0.2:2181 --topic TestTopic Topic: TestTopic TopicId: bdvxOQhATRGuoAnYQXwmUg PartitionCount: 5 ReplicationFactor: 3 Configs: Topic: TestTopic Partition: 0 Leader: 0 Replicas: 0,3,2 Isr: 0 Topic: TestTopic Partition: 1 Leader: 2 Replicas: 2,0,3 Isr: 2,0,3 Topic: TestTopic Partition: 2 Leader: 3 Replicas: 3,2,0 Isr: 3,2,0生产者 ACK 为 -1 默认情况:当生产者发送数据给broker时,会根据"Isr"查看当前同步的broker集群,把"Isr"中存在的broker同步好数据后生产者会收到确认 1."Isr"有全部broker集群。那么会把数据同步到所有broker,一个挂掉会选举新的leader持续服务 (可以保证高可用) 2. 如果"Isr"中只有leader。那么数据发送完其实也只有一台节点存储数据,当该节点挂掉依然无法正常使用该分区。(无法保证) 配合使用:min.insync.replicasmin.insync.replicas 最小同步副本数 和 ack = - 或 all 组合使用 当 ack = -1 或 all ,"Isr"中至少有"min.insync.replicas"副本数,包括leader,follow。如果没有这么多副本,生产者发送消息会抛出异常。 异常信息:消息被拒绝,因为同步复制副本的数量少于所需数量 NotEnoughReplicasException: Messages are rejected since there are fewer in-sync replicas than required.一般情况集群3台,ack为-1,min.insync.replicas为2

"数据先写入内存 buffer,然后每隔 1s,将数据 refresh 到 os cache,到了 os cache 数据就能被搜索到(所以我们才说 es 从写入到能被搜索到,中间有 1s 的延迟)。每隔 5s,将数据写入 translog 文件(这样如果机器宕机,内存数据全没,最多会有 5s 的数据丢失),translog 大到一定程度,或者默认每隔 30mins,会触发 commit 操作,将缓冲区的数据都 flush 到 segment file 磁盘文件中。"
我觉得第一句的说法我不太同意。数据是双写同时写入 buffer,和 translog,但是此时 translog 是在内存里,不刷盘,5s 以后或者足够大才可以刷盘写入translog 文件(写入磁盘)。

官方关于这段的描述:
原文摘录如下:
"All index and delete operations are written to the translog after being processed by the internal Lucene index but before they are acknowledged."

这句话说明了索引和删除操作在被 Lucene 索引处理之后,但在确认之前,会被写入 Translog。

"The data in the translog is only persisted to disk when the translog is fsynced and committed."

这句话说明了 Translog 数据仅在 Translog 被 fsync(确保数据写入磁盘)并提交后才被持久化到磁盘。

1

解决思路 2:延时双删。依旧是先更新数据库,再删除缓存,唯一不同的是,我们把这个删除的动作,在不久之后再执行一次,比如 5s 之后。
如果延时删除也失败,怎么办呢?