World of Tanks Experience of Using Kafka

Editor's Notes

• #5: Scalability, reliability, efficiency Главная цель - сделать расширяемую, надежную, эффективную систему •Occam's Razor The simplest design that satisfies all requirements should be considered the best, or in the words of Ein- stein, "Make things as simple as possible, but no simpler". •Improve the worst case In general (mainly when it comes to the client experience), the worst case should be improved over the average case. •Client/server bandwidth is valuable The most important resource is the bandwidth between the client and server. After this, it is probably CPU, and then intra-server bandwidth. •Keep information together; Avoid two-way calls Information (or data) that is often used together should be easily accessed together. • Avoid bottlenecks; Make the system distributed •Where possible, do communication in batches There is a fairly high overhead in sending a single packet. Лучше 1 большой, чем 10 маленьких
• #6: 5
• #7: 6
• #9: PRMP таргетированное предложение для пользователей.
• #11: 4 API Коннектор это встравить в уже готовые приложения Стриминг – чтобы строить стрим процессор
• #13: Это распределенный неизменяемый лог. Офсет. Ретеншен период Гарантии Порядок записи Порядок чтения
• #14: Лоад балансинг и фолт толеранс для разных консюмер групп
• #15: Выборы Подписка офсеты
• #16: Репликация. Лидер Выбывание реплики АКИ
• #21: Scalability, reliability, efficiency The general goal is to produce a scalable, reliable, and efficient system. This should be done while keeping as much simplicity and flexibility as possible. •Occam's Razor The simplest design that satisfies all requirements should be considered the best, or in the words of Ein- stein, "Make things as simple as possible, but no simpler". •Improve the worst case In general (mainly when it comes to the client experience), the worst case should be improved over the average case. For example, it is not beneficial to have a blinding fast and accurate situation when a client is not near a cell boundary if the experience is poor when he is near one. •Client/server bandwidth is valuable The most important resource is the bandwidth between the client and server. After this, it is probably CPU, and then intra-server bandwidth. •Keep information together; Avoid two-way calls Information (or data) that is often used together should be easily accessed together. For example, a large amount of the data processed together in the game is related to objects that are geometrically close. It makes sense then to use data partitioning based on locality. It is also expensive to have to request information from a separate server machine when it is necessary. This is true for a number of reasons including the extra hops and coordination required and (maybe even more importantly) the reduced likelihood of being able to batch requests together. •Avoid bottlenecks; Make the system distributed The design should try to avoid single central points where things occur. This approach can cause perfor- mance bottlenecks and make the design non-scalable. It can also introduce a single point of failure, there- fore raising fault tolerance issues. •Where possible, do communication in batches There is a fairly high overhead in sending a single packet. That is, it is a lot more expensive to send ten individual packets than it is to send one packet that is ten times bigger.
• #23: Scalability, reliability, efficiency The general goal is to produce a scalable, reliable, and efficient system. This should be done while keeping as much simplicity and flexibility as possible. •Occam's Razor The simplest design that satisfies all requirements should be considered the best, or in the words of Ein- stein, "Make things as simple as possible, but no simpler". •Improve the worst case In general (mainly when it comes to the client experience), the worst case should be improved over the average case. For example, it is not beneficial to have a blinding fast and accurate situation when a client is not near a cell boundary if the experience is poor when he is near one. •Client/server bandwidth is valuable The most important resource is the bandwidth between the client and server. After this, it is probably CPU, and then intra-server bandwidth. •Keep information together; Avoid two-way calls Information (or data) that is often used together should be easily accessed together. For example, a large amount of the data processed together in the game is related to objects that are geometrically close. It makes sense then to use data partitioning based on locality. It is also expensive to have to request information from a separate server machine when it is necessary. This is true for a number of reasons including the extra hops and coordination required and (maybe even more importantly) the reduced likelihood of being able to batch requests together. •Avoid bottlenecks; Make the system distributed The design should try to avoid single central points where things occur. This approach can cause perfor- mance bottlenecks and make the design non-scalable. It can also introduce a single point of failure, there- fore raising fault tolerance issues. •Where possible, do communication in batches There is a fairly high overhead in sending a single packet. That is, it is a lot more expensive to send ten individual packets than it is to send one packet that is ten times bigger.
• #24: Scalability, reliability, efficiency The general goal is to produce a scalable, reliable, and efficient system. This should be done while keeping as much simplicity and flexibility as possible. •Occam's Razor The simplest design that satisfies all requirements should be considered the best, or in the words of Ein- stein, "Make things as simple as possible, but no simpler". •Improve the worst case In general (mainly when it comes to the client experience), the worst case should be improved over the average case. For example, it is not beneficial to have a blinding fast and accurate situation when a client is not near a cell boundary if the experience is poor when he is near one. •Client/server bandwidth is valuable The most important resource is the bandwidth between the client and server. After this, it is probably CPU, and then intra-server bandwidth. •Keep information together; Avoid two-way calls Information (or data) that is often used together should be easily accessed together. For example, a large amount of the data processed together in the game is related to objects that are geometrically close. It makes sense then to use data partitioning based on locality. It is also expensive to have to request information from a separate server machine when it is necessary. This is true for a number of reasons including the extra hops and coordination required and (maybe even more importantly) the reduced likelihood of being able to batch requests together. •Avoid bottlenecks; Make the system distributed The design should try to avoid single central points where things occur. This approach can cause perfor- mance bottlenecks and make the design non-scalable. It can also introduce a single point of failure, there- fore raising fault tolerance issues. •Where possible, do communication in batches There is a fairly high overhead in sending a single packet. That is, it is a lot more expensive to send ten individual packets than it is to send one packet that is ten times bigger.
• #25: 24
• #26: Scalability, reliability, efficiency The general goal is to produce a scalable, reliable, and efficient system. This should be done while keeping as much simplicity and flexibility as possible. •Occam's Razor The simplest design that satisfies all requirements should be considered the best, or in the words of Ein- stein, "Make things as simple as possible, but no simpler". •Improve the worst case In general (mainly when it comes to the client experience), the worst case should be improved over the average case. For example, it is not beneficial to have a blinding fast and accurate situation when a client is not near a cell boundary if the experience is poor when he is near one. •Client/server bandwidth is valuable The most important resource is the bandwidth between the client and server. After this, it is probably CPU, and then intra-server bandwidth. •Keep information together; Avoid two-way calls Information (or data) that is often used together should be easily accessed together. For example, a large amount of the data processed together in the game is related to objects that are geometrically close. It makes sense then to use data partitioning based on locality. It is also expensive to have to request information from a separate server machine when it is necessary. This is true for a number of reasons including the extra hops and coordination required and (maybe even more importantly) the reduced likelihood of being able to batch requests together. •Avoid bottlenecks; Make the system distributed The design should try to avoid single central points where things occur. This approach can cause perfor- mance bottlenecks and make the design non-scalable. It can also introduce a single point of failure, there- fore raising fault tolerance issues. •Where possible, do communication in batches There is a fairly high overhead in sending a single packet. That is, it is a lot more expensive to send ten individual packets than it is to send one packet that is ten times bigger.
• #28: Scalability, reliability, efficiency The general goal is to produce a scalable, reliable, and efficient system. This should be done while keeping as much simplicity and flexibility as possible. •Occam's Razor The simplest design that satisfies all requirements should be considered the best, or in the words of Ein- stein, "Make things as simple as possible, but no simpler". •Improve the worst case In general (mainly when it comes to the client experience), the worst case should be improved over the average case. For example, it is not beneficial to have a blinding fast and accurate situation when a client is not near a cell boundary if the experience is poor when he is near one. •Client/server bandwidth is valuable The most important resource is the bandwidth between the client and server. After this, it is probably CPU, and then intra-server bandwidth. •Keep information together; Avoid two-way calls Information (or data) that is often used together should be easily accessed together. For example, a large amount of the data processed together in the game is related to objects that are geometrically close. It makes sense then to use data partitioning based on locality. It is also expensive to have to request information from a separate server machine when it is necessary. This is true for a number of reasons including the extra hops and coordination required and (maybe even more importantly) the reduced likelihood of being able to batch requests together. •Avoid bottlenecks; Make the system distributed The design should try to avoid single central points where things occur. This approach can cause perfor- mance bottlenecks and make the design non-scalable. It can also introduce a single point of failure, there- fore raising fault tolerance issues. •Where possible, do communication in batches There is a fairly high overhead in sending a single packet. That is, it is a lot more expensive to send ten individual packets than it is to send one packet that is ten times bigger.
• #29: Scalability, reliability, efficiency The general goal is to produce a scalable, reliable, and efficient system. This should be done while keeping as much simplicity and flexibility as possible. •Occam's Razor The simplest design that satisfies all requirements should be considered the best, or in the words of Ein- stein, "Make things as simple as possible, but no simpler". •Improve the worst case In general (mainly when it comes to the client experience), the worst case should be improved over the average case. For example, it is not beneficial to have a blinding fast and accurate situation when a client is not near a cell boundary if the experience is poor when he is near one. •Client/server bandwidth is valuable The most important resource is the bandwidth between the client and server. After this, it is probably CPU, and then intra-server bandwidth. •Keep information together; Avoid two-way calls Information (or data) that is often used together should be easily accessed together. For example, a large amount of the data processed together in the game is related to objects that are geometrically close. It makes sense then to use data partitioning based on locality. It is also expensive to have to request information from a separate server machine when it is necessary. This is true for a number of reasons including the extra hops and coordination required and (maybe even more importantly) the reduced likelihood of being able to batch requests together. •Avoid bottlenecks; Make the system distributed The design should try to avoid single central points where things occur. This approach can cause perfor- mance bottlenecks and make the design non-scalable. It can also introduce a single point of failure, there- fore raising fault tolerance issues. •Where possible, do communication in batches There is a fairly high overhead in sending a single packet. That is, it is a lot more expensive to send ten individual packets than it is to send one packet that is ten times bigger.