thảo luận Chuẩn bị phỏng vấn senior nodejs

Anh giải thích về việc NodeJS chạy như thế nào, ưu điểm, giả sử 1 server chạy 4 core/8 thread, mà nodejs chỉ dùng có 1 thread, vậy có phải thừa tài nguyên không ? Anh giải thích thế nào về việc này ạ ?
Em mới học Node.js xin mạn phép nêu quan điểm : Nói Node.js chỉ dùng có 1 thread thì không đúng lắm (trong thực tế 99% thời gian các ứng dụng Node chạy đa luồng chỉ có duy nhất code JS chúng ta viết chạy trên một luồng duy nhất là main thread) do trong Node.js sẽ sử dụng 2 loại thread là main thread và worker thread, với worker thread chủ yếu được sử dụng bởi thư viện libUV (được viết bằng C++) chuyên để xử lý các tác vụ nặng liên quan đến I/O, Networking...theo mặc định (có thể tăng hoặc giảm thread) thì Libuv sẽ được sử dụng 4 thread nên sẽ không thừa như bác nói đâu.
 
Vl senior 13 củ :))
Dm giờ fresher nó toàn đòi 15-20 củ kia kìa
Ban đầu tưởng 1k3 $ mình còn đang nghĩ thấp

Ngoài lề tí: mọi vấn đề cãi nhau chỉ kết thúc khi có 1 bên ignore bên còn lại :))))
 
Vl senior 13 củ :))
Dm giờ fresher nó toàn đòi 15-20 củ kia kìa
Ban đầu tưởng 1k3 $ mình còn đang nghĩ thấp

Ngoài lề tí: mọi vấn đề cãi nhau chỉ kết thúc khi có 1 bên ignore bên còn lại :))))
13 củ là nó cố tình deal thế để đuổi đi ấy mà. (Hoặc bác thread thái độ ....)
Mặt bằng chung thì KV cũng không trả cao. Em deal 2k mà họ cười như kiểu mình pvan vị trí C vậy.
Anh CTO cũng khá ổn về tech, nhưng không rõ vì sao cả team BI bên đó bay :))

via theNEXTvoz for iPhone
 
Em mới đi phỏng vấn nodejs ở vccorp về đây.
Họ hỏi điểm mạnh điểm yếu của nodejs, kỹ thuật cache nhiều tầng ( nếu miss thì làm thế nào), hỏi chi tiết các thuật toán mã hóa, cách phân chia các replication trong mongodb sao cho miss ít nhất, chút kiến thức về hệ điều hành ... vv còn nhiều lắm, mà em không nhớ, ấn tượng mỗi là họ hỏi chi tiết mấy cái thuật toán mã hóa ( cái này lúc học trên trường có môn atbm thì em nhớ chứ giờ em quên cmnr, SHA, md5, tri-des .vv ).
Mà họ đòi làm full time, giờ mình đang đi làm 1 chỗ nữa nên đi làm partime được thôi nên out, với cả trả lời cũng không tốt lắm.
Họ bảo có hỏi em cũng không biết vì nhìn cv của em ghi ít thứ quá, chắc gì những thứ bọn anh hỏi em đã biết, nên hỏi để đấy chứ không cho mình cơ hội trả lời. :v đợt trước mình ghi nhiều đi phỏng vấn chỗ khác thì có ông lại bảo ghi nhiều thế này chắc gì em đã trả lời được.
mà họ bảo lương có 4 củ nên em cũng hơi nhụt chí :v
 
Em mới đi phỏng vấn nodejs ở vccorp về đây.
Họ hỏi điểm mạnh điểm yếu của nodejs, kỹ thuật cache nhiều tầng ( nếu miss thì làm thế nào), hỏi chi tiết các thuật toán mã hóa, cách phân chia các replication trong mongodb sao cho miss ít nhất, chút kiến thức về hệ điều hành ... vv còn nhiều lắm, mà em không nhớ, ấn tượng mỗi là họ hỏi chi tiết mấy cái thuật toán mã hóa ( cái này lúc học trên trường có môn atbm thì em nhớ chứ giờ em quên cmnr, SHA, md5, tri-des .vv ).
Mà họ đòi làm full time, giờ mình đang đi làm 1 chỗ nữa nên đi làm partime được thôi nên out, với cả trả lời cũng không tốt lắm.
Họ bảo có hỏi em cũng không biết vì nhìn cv của em ghi ít thứ quá, chắc gì những thứ bọn anh hỏi em đã biết, nên hỏi để đấy chứ không cho mình cơ hội trả lời. :v đợt trước mình ghi nhiều đi phỏng vấn chỗ khác thì có ông lại bảo ghi nhiều thế này chắc gì em đã trả lời được.
mà họ bảo lương có 4 củ nên em cũng hơi nhụt chí :v

cache nhiều tầng là sao nhỉ ? Ý là cache L1 L2 L3 ấy à ?
còn mấy thuật toán thì đụng vào mới nhớ dc chứ, giờ hỏi mình sha, md5 nó hoạt động kiểu gì mình cũng chả nhớ :surrender:

4 củ chắc troll
 
13 củ là nó cố tình deal thế để đuổi đi ấy mà. (Hoặc bác thread thái độ ....)
Mặt bằng chung thì KV cũng không trả cao. Em deal 2k mà họ cười như kiểu mình pvan vị trí C vậy.
Anh CTO cũng khá ổn về tech, nhưng không rõ vì sao cả team BI bên đó bay :))

via theNEXTvoz for iPhone

Mình thấy hơi lạ, vì nếu thế thì cho tạch luôn đi chứ deal 13 buồn cười thế nhỉ :-/
 
BỌn KV phèn vl ra. Làm việc thì tệ hại vl.
Cty e đang dùng đồ của KV, giờ đang build 1 cái riêng để đếu phụ thuộc vào KV nữa.
 
Mình thấy hơi lạ, vì nếu thế thì cho tạch luôn đi chứ deal 13 buồn cười thế nhỉ :-/

ngu gì, biết đâu có thằng chịu :LOL:

nói mức trả và cách làm việc điếm đàng rồi, qua thread review cty report cho mọi người biết, kiểu này mất thời gian vcc.
 
cache nhiều tầng là sao nhỉ ? Ý là cache L1 L2 L3 ấy à ?
còn mấy thuật toán thì đụng vào mới nhớ dc chứ, giờ hỏi mình sha, md5 nó hoạt động kiểu gì mình cũng chả nhớ :surrender:

4 củ chắc troll
nghĩa là tầng 1 thì cache với redis hoặc database tốc độ cao nào đó, tầng 2 mới ghi vào mongodb, cái này em chưa cài đặt thực tế bao giờ. chỉ đọc qua thôi.
Còn về nguyên lí thì giống với việc hệ điều hành sử dụng cache và ram, mục đích vẫn là tăng tốc độ và giảm giá thành nhờ việc ghi ra các bộ nhớ tốc độ cao, nhờ vậy mà không cần phải chờ đợi các bộ nhớ tốc độ thấp hơn phản hồi, khi nào rảnh thì sẽ ghi ra các bộ nhớ tốc độ thấp hơn sau.
mà với db thì chắc chỉ cache các thao tác get chứ mấy thao tác update thì cache kiểu gì nhỉ.
Em không thèm nói vụ 4 củ luôn, biết trước là không vào vì full time rồi.
 
nghĩa là tầng 1 thì cache với redis hoặc database tốc độ cao nào đó, tầng 2 mới ghi vào mongodb, cái này em chưa cài đặt thực tế bao giờ. chỉ đọc qua thôi.
Còn về nguyên lí thì giống với việc hệ điều hành sử dụng cache và ram, mục đích vẫn là tăng tốc độ và giảm giá thành nhờ việc ghi ra các bộ nhớ tốc độ cao, nhờ vậy mà không cần phải chờ đợi các bộ nhớ tốc độ thấp hơn phản hồi, khi nào rảnh thì sẽ ghi ra các bộ nhớ tốc độ thấp hơn sau.
mà với db thì chắc chỉ cache các thao tác get chứ mấy thao tác update thì cache kiểu gì nhỉ.
Em không thèm nói vụ 4 củ luôn, biết trước là không vào vì full time rồi.

À hiểu, cái này thì trc mình làm ở Z*** có xài. Gọi là multiple layer caching. Cache CDN, cache proxy, cache server, rồi cache db. Đơn giản là nhiều lớp cache bù trừ cho nhau để tăng hit rate thôi.
 
Last edited:
nghĩa là tầng 1 thì cache với redis hoặc database tốc độ cao nào đó, tầng 2 mới ghi vào mongodb, cái này em chưa cài đặt thực tế bao giờ. chỉ đọc qua thôi.
Còn về nguyên lí thì giống với việc hệ điều hành sử dụng cache và ram, mục đích vẫn là tăng tốc độ và giảm giá thành nhờ việc ghi ra các bộ nhớ tốc độ cao, nhờ vậy mà không cần phải chờ đợi các bộ nhớ tốc độ thấp hơn phản hồi, khi nào rảnh thì sẽ ghi ra các bộ nhớ tốc độ thấp hơn sau.
mà với db thì chắc chỉ cache các thao tác get chứ mấy thao tác update thì cache kiểu gì nhỉ.
Em không thèm nói vụ 4 củ luôn, biết trước là không vào vì full time rồi.

Cache trong DB thì nó có nhiều loại.

Ví dụ đơn giản như sau trong cassandra:
  • Partition key cache
  • Row cache
Khi read operation hit row cache thì trả về row đó luôn mà ko cần thao tác disk seek. Trong row cache ko có thì check tới key cache.

Mỗi loại DB thì có những kiểu cache khác nhau nữa, nhưng cơ chế thì gần giống giống nhau.
 
Em mới đi phỏng vấn nodejs ở vccorp về đây.
Họ hỏi điểm mạnh điểm yếu của nodejs, kỹ thuật cache nhiều tầng ( nếu miss thì làm thế nào), hỏi chi tiết các thuật toán mã hóa, cách phân chia các replication trong mongodb sao cho miss ít nhất, chút kiến thức về hệ điều hành ... vv còn nhiều lắm, mà em không nhớ, ấn tượng mỗi là họ hỏi chi tiết mấy cái thuật toán mã hóa ( cái này lúc học trên trường có môn atbm thì em nhớ chứ giờ em quên cmnr, SHA, md5, tri-des .vv ).
Mà họ đòi làm full time, giờ mình đang đi làm 1 chỗ nữa nên đi làm partime được thôi nên out, với cả trả lời cũng không tốt lắm.
Họ bảo có hỏi em cũng không biết vì nhìn cv của em ghi ít thứ quá, chắc gì những thứ bọn anh hỏi em đã biết, nên hỏi để đấy chứ không cho mình cơ hội trả lời. :v đợt trước mình ghi nhiều đi phỏng vấn chỗ khác thì có ông lại bảo ghi nhiều thế này chắc gì em đã trả lời được.
mà họ bảo lương có 4 củ nên em cũng hơi nhụt chí :v
May quá nhờ bạn review mà mình né VCC ra. HR thấy nhiệt tình vậy mà lương lậu bullshit quá nhỉ.
Fresher giờ chúng nó còn đòi min $600 rồi :surrender:

via theNEXTvoz for iPhone
 
cache mình thấy mệt nhất là vụ consistent, trước 1 dự án chuối nó làm thuần redis, còn query thì dùng raw sql :LOL:, data nào cần cache thì dùng redis, lúc lấy ra thì xem redis chưa có thì query db rồi set vào redis lại.

Nhưng mỗi khi update thông tin thì phải biết mà xóa redis key đi. Mà bạn tưởng tượng dữ liệu trong redis là tổng hợp của nhiều bảng, trong khi 1 api nó chỉ sửa 1 bảng thì méo biết đường nào mà xóa cache. Chưa kể 1 bảng đó nó join ra nhiều dữ liệu -> nhiều key. Do app lúc đó còn nhỏ và cũng hạn chế cache nên vẫn còn kiểm soát được.

Mình đang muốn tìm 1 cơ chế tự động nào đó, các bác có biết ko. Mình đang nghĩ cái hướng là nếu dùng model thì mình list được các key liên quan tới model đó, nếu sửa/xóa model thì nó cũng trigger để xóa các key tương ứng.
 
cache mình thấy mệt nhất là vụ consistent, trước 1 dự án chuối nó làm thuần redis, còn query thì dùng raw sql :LOL:, data nào cần cache thì dùng redis, lúc lấy ra thì xem redis chưa có thì query db rồi set vào redis lại.

Nhưng mỗi khi update thông tin thì phải biết mà xóa redis key đi. Mà bạn tưởng tượng dữ liệu trong redis là tổng hợp của nhiều bảng, trong khi 1 api nó chỉ sửa 1 bảng thì méo biết đường nào mà xóa cache. Chưa kể 1 bảng đó nó join ra nhiều dữ liệu -> nhiều key. Do app lúc đó còn nhỏ và cũng hạn chế cache nên vẫn còn kiểm soát được.

Mình đang muốn tìm 1 cơ chế tự động nào đó, các bác có biết ko. Mình đang nghĩ cái hướng là nếu dùng model thì mình list được các key liên quan tới model đó, nếu sửa/xóa model thì nó cũng trigger để xóa các key tương ứng.
Bạn muốn kiểm soát nó , bạn phải chia luồng ra.

Quy tắc tối quan trọng là phải tách bạch 2 luồng Read/Write . Cách bạn phân chia folder cũng là 1 nghệ thuật rồi (hãy tập làm quen với nó trước)

1. Cache Api: Đối với từng microservice phải có hotkey riêng,version riêng cho từng dịch vụ cụ thể và phải ép toàn bộ mọi người theo quy chuẩn bạn đề ra trong project đó. Key request cần tuân theo 1 chuẩn hàm băm để tránh việc params out size limit key redis

2. Cache database : phần này mình ko có gì để nói với bạn vì đa phần các loại database mà mình làm trước giờ bản thân trong engine của nó đã có thuật toán cache sẵn rồi, bạn làm nhiều khi còn down hơn và khó controll hơn . Tuy nhiên, tốt thôi , nếu làm thì cũng phải theo nguyên tắc của bạn , thông thường nó phải có rule ngay từ lúc bạn dựng database

Ok, sao khi đã hiểu vấn đề thì vào dựng 1 cái lib đơn giản cho riêng mình thôi, ép vào middleware trước ( đối với read) và middleware sau(đối với write)
Chúc may mắn :love:
 
Back
Top