Bài viết được sự cho phép của tác giả Nguyễn Hồng Quân

Là một nhà phát triển web, bạn có thể đã biết đến Iconify, một kho dữ liệu icon dành cho web cực kỳ phong phú, tổng hợp từ nhiều bộ khác nhau (FontAwesome, Material Design v.v…) để đưa về một cách sử dụng chung. Tôi cũng không ngoại lệ, cũng sử dụng Iconnify trong nhiều dự án, vì ngoài việc tích hợp dễ dàng vào dự án, Iconify còn cho phép trộn lẫn nhiều bộ, vì nhiều khi hình ảnh mà tôi cần không tồn tại trong bộ này mà chỉ có ở bộ kia (bạn có thể lo ngại việc trộn lẫn khiến phong cách hình ảnh không thống nhất, đành chịu, vì với người không có khả năng thiết kế thì phải chấp nhận thôi).

Để có được ưu điểm kể trên, Iconify không bắt bạn phải đóng gói hết nội dung icon của các bộ cần dùng, mà dùng cơ chế gọi API để lấy về nội dung của icon khi cần (và nội dung này cũng được lưu trữ tạm để khỏi gọi API lại nhiều lần).

Với phần lớn trường hợp thì cách làm này là ổn, nhưng một số trường hợp thì nó lại gây băn khoăn. Ví dụ với một sản phẩm IoT, khi mà website đó chạy trong mạng nội bộ, để có thể tự hành khi rớt Internet, hoặc được truy cập ở vùng sâu vùng xa nơi điều kiện Internet không tốt, khi việc gọi API lấy nội dung icon có thể thất bại và ảnh hưởng xấu đến giao diện website. Với những trường hợp như thế thì tôi phải tìm cách thu thập nội dung icon và đính kèm theo website, để không phải gọi API nữa.

Sau đây là cách làm với Vue 3. Cách này không được chỉ dẫn trong tài liệu của Iconify nên tôi phải tự mò.

Nội dung icon dành cho việc sử dụng offline được Iconify phân phối trên NPM Registry, nên bạn có thể kèm nó dưới dạng dependency của ứng dụng JavaScript.

Ví dụ icon saucó tên ri:shield-user-line, thuộc bộ Remix Icon thì bạn cần thêm gói @iconify-icons/ri vào danh sách dependency:

$ yarn add @iconify-icons/ri

Tiếp đến, trong code Vue, trong component nào mà bạn dùng đến icon này, thêm vào các dòng sau:

import { addIcon } from '@iconify/vue'
import iShieldUser from '@iconify-icons/ri/shield-user-line'

addIcon('ri:shield-user-line', iShieldUser)

Trên phần <template></template>, bạn vẫn sử dụng icon như khi không cần offline:

<Icon icon='ri:shield-user-line' />

Khi gọi addIcon(), bạn có thể truyền chuỗi bất kì vào tham số thứ nhất, để đặt tên khác cho icon, miễn sao khi sử dụng trong <template/> thì bạn phải truyền tên tương ứng vào <Icon icon='' />. Tôi thì vẫn dùng tên cũ, để thuận tiện cho việc tra tìm cũng như không gây đứt gãy nếu sau này muốn bỏ việc đính kèm offline.

Như vậy là xong, khi bạn build bằng Vite, nội dung của icon ri:shield-user-line sẽ được kèm vào source website và không bị phụ thuộc vào API nữa. Ngoài ra, nhờ được Iconify tổ chức sao cho hỗ trợ tree-shaking nên chỉ có nội dung của icon kia được kèm thêm, thay vì cả trăm icon của bộ Remix Icon. Điều bất ngờ là trong tài liệu của Iconify, trang Icon bundles for Iconify for Vue lại hướng dẫn cách làm khác và hơi khó thực hiện (có lẽ tài liệu cũ không được cập nhật).

Bài viết gốc được đăng tải tại quan.hoabinh.vn

Tham khảo thêm:

• Ứng dụng thuật toán và cấu trúc dữ liệu lúc đi làm
• Cách Giao Tiếp Giữa Các Service Trong Hệ Thống Có Tải Cao
• Dùng Python viết hàm xử lý dữ liệu dưới tầng database cho PostgreSQL

Đừng bỏ lỡ nhiều việc làm Developer, Designer, UI/UX,… trên Topev nhé!

Bài viết được sự cho phép của tác giả Trần Thiện Khiêm

Trong loạt bài này mình sẽ giới thiệu về thuật toán và một số thuật toán cơ bản hay được sử dụng + giải thích cho các bạn.

THUẬT TOÁN LÀ GÌ?

Nhưng đầu tiên hết hãy tìm hiểu xem thuật toán là gì? Nói đơn giản thuật toán là:

“Tập hợp các bước để xử lí một vấn đề (loại vấn đề) nào đó.”

Ví dụ, để tính tổng các số tự nhiên từ 1 – N, thì chúng ta làm các bước sau (1)

– Gán tổng = 0

– Cộng tổng với 1

– Cộng tổng với 2

…

– Cộng tổng với n

– Ta được kết quả tổng là kết quả.

Hay nói một cách khác (2)

– Gán Tổng = 0

– Lần lượt với tất cả giá trị i trong đoạn 1 tới N, cộng i vào tổng

Hoặc có 1 cách khác (3)

– Tính tổng = N * (N + 1) / 2.

Như vậy các bước giải vấn đề, người ta gọi là thuật toán. Vậy bất cứ khi nào các bạn viết code, thì đó chính là thuật toán. Nên nếu có ai đó nói với bạn rằng, học thuật toán làm gì sau này đi làm không có dùng thuật toán, thế thì hãy hỏi lại: “không xài thuật toán thì bạn code cái gì vậy?”. Không có vụ không có thuật toán mà có code nhé, chỉ có thuật toán ngon hay dở thôi.

Tất nhiên đối với một vấn đề, có thể có nhiều cách giải quyết khác nhau, có cách giải quyết nhanh chóng, có cách giải chậm, có cách giải đơn giản, có cách giải phức tạp, đó là lý do học thuật toán. Đó là lí do tại sao người ta có senior dev, có junior. Đó cũng là lí do tại sao mấy công ty lớn người ta lại hỏi về thuật toán. Học thuật toán, chúng ta học gì:

– Học tư duy thuật toán để khi có một vấn đề mới chúng ta biết cách tiếp cận, biết cách đánh giá lời giải chúng ta đưa ra.

– Học các thuật toán phổ biến để khi gặp trường hợp tương tự chúng ta biết cách sử dụng mà không phải tốn thời gian nghĩ ra các lời giải khác. Thường thường các thuật toán này đã đươc viết lại dạng thư viện, nên chúng ta có thể dựa vào đó để tìm ra thư viện tương ứng để xài, vừa đạt hiệu quả cao nhất, mà không phải tốn công giải lại (nói nôm na là copy và paste ở 1 đẳng cấp khác).

ĐÁNH GIÁ THUẬT TOÁN

Thường chúng ta có thể dùng phương pháp đo thời gian chạy (benchmark) để đánh giá xem thuật toán đưa ra có hiệu quả không. Đây là cách chính xác nhất. Tuy nhiên, cách này có một nhược điểm là chúng ta phải code xong thuật toán đó, và nó hoàn toàn phụ thuộc vào kích thước mẫu của dữ liệu đưa vào. Cách này có thể các bạn sẽ thấy khi các bạn submit bài leetcode, nếu timeout thì chắn tỏ thuật toán của toán của bạn quá cùi

Có 1 cách đánh giá khác đơn giản hơn trước khi bạn code đó là đánh giá dựa vào độ phức tạp thời gian (time complexity). Chúng ta có thể đánh giá ngay thuật toán trước khi code, để xem thuật toán có khả thi hay không.

VẬY ĐỘ PHỨC TẠP THỜI GIAN LÀ GÌ?

Nôm na độ phức tạp thời gian của thuật toán là ước lượng thời gian thực thi của thuật toán đó theo kích thước dữ liệu đầu vào. Chính vì có sự phụ thuộc này nên độ phức tạp thuật toán được biểu diễn dưới dạng hàm số O(1), O(N), O(N2), nghe thật đau đầu và khó hiểu…

Vậy mình xin có 1 số ví dụ như sau:

Với bài toán nêu trên, tính tổng của các số tự nhiên từ 1 .. N, chúng ta có 3 cách, tuy nhiên cách đầu tiên khó mà tổng quát hoá được, nên chúng ta sẽ tập trung vào cách (2), và cách (3).

Với cách số (2), chúng ta phải tính N phép tính cộng, giả sử một phép tính tốn 1ms (giả sử máy tính cùi bắp nha), thì ta có kết quả sau:

N = 1, thời gian là 1ms.

N = 2, thời tian là 2ms,

N = 10, thời gian là 10ms. (vì phải cộng 10 lần)

Ta thấy thời gian tỉ lệ thuận với N, do đó ta gọi thuật toán này có độ phức tạp tuyến tính (linear complexity) hay O(N), nếu N tăng lên 10 lần, thì thời gian của thuật toán sẽ tăng thêm 10 lần, nếu N tăng lên 1000 lần, thời gian sẽ tăng lên 1000 lần.

Đối với cách (3), cho dù với N bằng bao nhiêu đi nữa, thì chúng ta chỉ cần 1 phép tính toán như nhau để tìm ra kết quả. Vậy thời gian không hề phụ thuộc vào dữ liệu đầu vào. Người ta gọi đây là độ phức tạp hằng số (constant time), hay O(1). Ví dụ, nếu thời gian để thực hiện công thức tên tốn 3ms, thì với bất cứ N nào, cũng sẽ tốn 3ms (với lí tưởng là thời gian thực thi của máy tính như nhau).

MỘT SỐ VÍ DỤ KHÁC

Thuật toán tìm kiếm tuần tự:

Giả sử chúng ta cần tìm một phần tử trong danh sách cho sẵn, thì chúng ta phải lần lượt kiểm tra từng phần tử cho đến khi tìm thấy phần tử cần tìm, đây gọi là thuật toán tìm kiếm tuần tự.

Ứng dụng:

String.indexOf(), Collection.indexOf(): xác định vị trí 1 ký tự trong chuỗi hoặc một phần tử trong Collection. Những thứ các bạn xài hằng ngày.

SELECT id FROM TABLE WHERE AGE=30; tìm một thành phần trong một bảng cơ sở dữ liệu mà cột chưa được đánh index.

Độ phức tạp: tuyến tính hay O(N).

Các bạn sẽ thắc mắc, là chúng ta có cần phải chạy hết N phần tử đâu, vì sao vẫn gọi là O(N), nếu phần tử cần tìm của mình nằm ở vị trí số 1, hoặc số 2, thì mình sẽ tìm ra ngay, và rõ ràng không cần chạy hết N bước.

Giải thích: giả sử phân bố của tất cả các phần tử là như nhau, thì với N phần tử, số bước tính trung bình của thuật toán này là xấp xỉ N/2 bước. Bây giờ, mình tăng N lên 10 lần, thì số bước trung bình của thuật toán này là xấp xỉ 10N/2. (10N/2) / (N/2) thì vẫn là tăng lên 10 lần, đảm bảo định nghĩa của O(N).

Rõ ràng, với độ phức tạp như thế này, các bạn sẽ cần phải cân nhắc sử dụng các thuật toán tìm kiếm tốt hơn nếu bộ dữ liệu của mình đủ lớn, hoặc nếu thuật toán này được gọi trong một vòng lặp khác. Vậy có những thuật toán tìm kiếm nào khác…

Nếu không biết thì xem độ phức tạp này ở đâu?

Trường hợp của các hàm có sẵn trong thư viện, chúng ta có thể tra document của ngôn ngữ đó để tìm ra độ phức tạp, hoặc google…

Với SQL chúng ta có thể sử dụng câu lệnh EXPLAIN

Nếu còn không tìm ra thì lo học đi ạ…

(còn tiếp…)

Bài viết gốc được đăng tải tại fanpage Khiem Tran – Programmer

Hiểu thêm về thuật toán, nếu bạn muốn:

• Ứng dụng thuật toán và cấu trúc dữ liệu lúc đi làm
• 10 thuật toán hàng đầu dành cho lập trình viên
• Thuật toán tìm kiếm trong C++

Đừng bỏ lỡ việc làm IT lương cao trên TopDev nhé!

Sau bao ngày chờ mong, BTC sự kiện Vietnam Mobile Day 2022 xin được công bố AGENDA (dự kiến) cho ngày hội tại khu vực Hồ Chí Minh (03/06/2022)!

Vietnam Mobile Day 2022 – We Connect – Sân chơi quen thuộc của cộng đồng yêu Công Nghệ tại Việt Nam, nay đã trở lại dưới hình thức Offline. Trong lần tái xuất này, sự kiện hứa hẹn mang đến cho mỗi cá nhân, nhà phát triển và các doanh nghiệp một không gian công nghệ thực sự bùng nổ – Nơi hội tụ của những sáng kiến công nghệ Mobile đột phá cùng các xu hướng mới nhất trên thị trường IT Việt Nam & khu vực.

Sự kiện năm nay sẽ là cơ hội để bạn “kết nối” cùng các diễn giả đầy nhiệt huyết và lắng nghe chia sẻ từ họ về các từ khóa HOT hiện nay như #Web3, #5G, #MCommerce, #Blockchain,… qua hơn 80+ chủ đề chất lượng về xu hướng & công nghệ Mobile trong năm 2022. Hãy cùng khám phá AGENDA Vietnam Mobile Day 2022 và “note” lại những Topic “hợp gu” để không bỏ lỡ những nội dung hấp dẫn tại ngày hội năm nay!

STAGE 1:

> Topic: The Hidden Value of Apps

> Topic: Giới thiệu về TikTok Shop – Nơi giải trí kết hợp cùng mua sắm

> Topic: Building Sustainable Security for 5G with Zero Trust

> Topic: Bí quyết vận dụng Data Analytics (Phân Tích Dữ Liệu) để tối đa hóa hiệu suất marketing cho Apps (Ứng Dụng Công Nghệ)

> Topic: Automation Marketing

> Topic: The Next Genaration Of Mobile Measurement

> Topic: Maximize Customers Engagement with Facebook N-Time notification on Mobile – Tối đa tương tác khách hàng với hệ thống thông báo định kỳ trên Facebook

> Topic: Làn sóng NFT và các mô hình ứng dụng trong SocialFi thế hệ mới

> Topic: Go-to-market in Web3 Jennie Thanh Head Of Community | Umbala Metaverse Inbound marketing for Mobile

> Topic: Xu hướng Marketing cho brand bằng Metaverse

> Topic: Mobile CRM yếu tố sống còn cho sale man sau Covid 19

> Topic: Câu chuyện thực tế tăng trưởng 200% doanh số nhờ Chuyển đổi số từ Offline lên Online

> Topic: Mobile Sales, CRM & Service: Công thức bí mật sau đại dịch cho đội ngũ Bán hàng & Dịch vụ

> Topic: Unlock the full potential of Metaverse!

STAGE 2:

> Topic: [Updating]

> Topic: Mobile First trong lĩnh vực Blockchain – Crypto

> Topic: Why Mobile Commerce has Become Critical for Retailers

> Topic: Ứng dụng giải pháp Social Marketing tăng trưởng trong Mobile Commerce

> Topic: Customer preferences in mobile first strategy

> Topic: API ngân hàng Việt Nam: Làm sao để truy cập?

> Topic: How to utilize Data in Pharmacy Retail industry

> Topic: Data Products for Mobile Commerce in Real-time and Real-life

> Topic: From Mobile Banking to Digital Banking, a great evolution

> Topic: Người Việt, năng lực Việt, ngồi ở Việt Nam nhưng vươn tầm Thế giới

> Topic:Open UI Components trong xu thế kết nối dòng chảy tài chính

> Topic: AIoT: Understanding the Applications of a New-Gen Convergence

> Topic: Mobile: Chiến lược thực thi Super App cho mảng IoT, và SaaS

> Topic:: Đặc trưng về kỹ thuật trong việc phát triển ứng dụng mobile so với ứng dụng web.

STAGE 3:

> Topic: [Updating] 

> Topic: Mobile App Development – What you don’t know

> Topic: Fast Mobile App Development

> Topic: Mobile First Approach & Strategy

> Topic:Ứng dụng mobile trong kết nối các nguồn lực trong và ngoài doanh nghiệp

> Topic: How to start auditing digital marketing data to grow your business on mobile

> Topic:Mobile App – Lối Đi Nào Cho Doanh Nghiệp?

> Topic: User Experience for Logistics Mobile End-Users

> Topic: Drive B2B Transformation with eCommerce and Integration Platform

> Topic: [updating]

> Topic: [Web3] Building a NFT Marketplace DApp like OpenSea

> Topic: Xây dựng nền tảng trên di động cho ngành TMĐT: xây gì và vì sao?

> Topic: Rule-Based Bots or AI Bots. Which is best for a chatbot project?

Cùng đếm ngược thời gian và chuẩn bị tâm thế để cùng bùng nổ trong không khí sôi động của ngày hội Vietnam Mobile Day 2022 bạn nhé!

Để đăng ký tham dự chương trình Vietnam Mobile Day 2022 vui lòng để lại thông tin tại đây

Bài viết được sự cho phép của tác giả Trần Văn Dem

Tại sao không nên dùng Http1.1 để giao tiếp giữa các service trong hệ thống có tải cao

Để thiết kế một hệ thống tin cậy có thể chịu được tải cao thì chúng ta cần quan tâm rất nhiều yếu tố :

• database : nosql, sql, in-mem database, index, partition,…
• caching
• design service
• load balance
• …

Thời điểm hiện nay chúng ta sẽ dễ dàng tìm được các bài báo cũng như các bài hướng dẫn, so sánh về các mục bên trên. Thời điểm hiện tại đa số các hệ thống sẽ được xây dựng trên mô hình microservice nhưng khi sử dụng mô hình trên thì còn một điều khá quan trọng chúng ta cần phải quan tâm đó là cách giao tiếp giữa các service với nhau (service communicate). Khi mới bắt đầu vào lập trình hầu hết các bài báo cũng như hướng dẫn tôi được đọc thì họ đều sử dụng http1 để lấy làm ví dụ cho hệ thống của họ. Nhưng trong quá trình trải nghiệm trong thực tế tôi thấy việc sử dụng http1 có rất nhiều hạn chế khi hệ thống gặp tải cao. Tại bài viết này với kinh nghiệm cá nhân của mình thì mình sẽ chia sẻ cho mọi người biết các hệ thống có tải cao của mình từng làm sẽ dùng cách thức nào để giao tiếp với nhau.

Giới thiệu một chút các hệ thống tải cao và yêu cầu độ trễ thấp mình từng làm là :

• Hệ thống Antispam của Viettel
• Sàn Trading của công ty Nextop.asia

1. TCP Socket

Vì tất cả hệ thống của mình đều sử dụng TCP nên mình sẽ chỉ chia sẻ về TCP tại đây. TCP là một giao thức truyền tin qua mạng có đảm bảo dữ liệu được truyền tải thành công điểu này mọi người đều đã biết. Hầu hết các giao thức khác đều dựa trên TCP và UDP nên việc biết về 2 mô hình socket này trước là điều cần thiết.

1.1. Client

Chúng ta có một ví dụ đơn giản về một TCP client đơn giản bằng ngôn ngữ Java. Đây là một ví dụ trên mạng

import java.net.*;  
import java.io.*;  
class MyClient{  
public static void main(String args[])throws Exception{  
Socket s=new Socket("localhost",3333);  
DataInputStream din=new DataInputStream(s.getInputStream());  
DataOutputStream dout=new DataOutputStream(s.getOutputStream());  
BufferedReader br=new BufferedReader(new InputStreamReader(System.in));  

String str="",str2="";  
while(!str.equals("stop")){  
str=br.readLine();  
dout.writeUTF(str);  
dout.flush();  
str2=din.readUTF();  
System.out.println("Server says: "+str2);  
}  

dout.close();  
s.close();  
}}

Để tạo ra một kết nối TCP thì chương trình sẽ phải tốn những tài nguyên sau :

• file descriptor (mỗi TCP connection đều cần 1 file descriptor) khoảng 4KB.
• Buffer size của kết nối TCP.
• Chi phí mạng.
• Một Thread đọc dữ liệu từ server trả lại.

Chi phí này là khá lớn và nếu quá nhiều kết nối TCP cùng tồn tại thì sẽ gây quá tải cho hệ thống của bạn.

1.2. Server

Với server lượng chi phí của chúng ta cũng sẽ mất tương tự như phía client nếu sử dụng mô hình Blocking IO (một số server nổi tiếng đang sử dụng mô hình này). Nhưng nếu sử dụng mô hình Non Blocking IO thì chi phí sẽ thấp hơn vì không nhất thiết phải tạo luồng mới để đọc dữ liệu của client gửi lên. Mọi người nếu chưa biết về 2 mô hình socket này thì nên tham khảo trên mạng.

Nhưng có một điều lưu ý là số lượng TCP connection của một server sẽ có giới hạn. Theo lý thuyết thì một TCP connection sẽ bao gồm (source IP, source port, dest IP, dest port) vậy số lượng connection tối đa một server có thể có sẽ là 2^48. Vì số connection chỉ phụ thuộc vào :

• số lượng source IP 2^32 và
• source port 2^16 connection có thể xảy ra. Nhưng thực tế sẽ dựa vào nhiều yếu tố khác:
• OS: số lượng file descriptor tối đa của hệ điều hành có thể mở ra (mỗi TCP connection đều cần 1 file descriptor). Trên linux kiểm tra bằng lệnh ulimit -a
• RAM : không tính đến buffer của mỗi socket thì mỗi file descriptor sẽ có dung lượng khoảng 4KB.

Vậy nếu điều kiện nào đến trước thì đó sẽ là giới hạn của server của hệ thống.

2. Http1.1

Mọi người không ai còn xa lạ với giao thức này nữa. Tại giao thức này đã cho phép chúng ta khả năng pipeline request nhưng khi dùng pipeline thì các request và response phải được gửi và nhận lần lượt. Nếu điều này bị vi phạm sẽ dẫn đến client không thể biết response này là của client nào. Tiếp đến nếu một request không may bị thất lạc thì khiến các request khác trong pipeline sẽ không được gửi lên server điều này sảy ra tình huống HOL gây giảm hiện năng. Vì những lý do trên nên hiện tại mình chưa từng dùng được một thư viện nào hỗ trợ mình chức năng pipeline của Http1.1.

Điểm yếu của Http1.1

Như phần trên chúng ta có thể nhận ra điểm yếu của Http1.1 đó chính là chúng ta sẽ không thể tái sử dụng một Http connection để gửi request nếu nó chưa nhận được response của server. Trong khi hệ thống cao tải thì chúng ta cần gửi rất nhiều request cùng một lúc đến các service khác nhau điều này bắt buộc chúng ta phải tạo ra rất nhiều Http connection và như đã biết việc tạo ra nhiều Http connection bên trên sẽ gây quá tải cho hệ thống của các bạn.

Tất nhiên các thư viện viết Http1.1 client đều cho phép bạn tạo connection pool nhưng khi hết connection trong pool một số thư viện sẽ tạo mới (tốn kém tài nguyên ), một số sẽ cố gắng đợi connection được trả lại trong pool điều này sẽ khiến các request mới sẽ không được gửi gây giảm hiệu năng hệ thống của bạn xuống.

Vậy nên hệ thống bạn mà giao tiếp dựa trên http1.1 thì sẽ là hệ thống synchronous, hệ thống này sẽ không thể đáp ứng được những ứng dụng có tải cao và yêu cầu độ trễ thấp.

Các bạn sẽ có thể bị bối rối việc các thư viện http1.1 cho phép sử dụng các asynchronous api? Các thư viện đó thực chất sẽ sử dụng các Thread khác để thực hiện request của bạn chứ không sử dụng chỉ Thread của bạn nên tốc độ của khi gửi request sẽ tốt hơn. Nhưng đứng dưới góc độ của Http connection nó vẫn sẽ là synchronous.

3. Cách thay thế Http1.1

3.1. Http2

Câu trả lời của hầu hết mọi người là Http2 vì nó quá nổi tiếng mà.

Tất nhiên việc nâng cấp lên Http2 cũng không hề dễ dàng như mọi người nghĩ. Mình đã từng làm một bài về Http2 in real project mình cảm thấy các thư viện Http2 client hiện tại vẫn chưa hỗ trợ hết tính năng của Http2 nếu cần thì bạn hơn thì bạn cần viết một client dành cho riêng mình. Với mình thì là tự viết client để giao tiếp với APNS của Apple.

Mình cũng đã thử config Http2 server trên spring-boot với tomcat và cũng cảm thấy khi config server này bằng spring-boot hiện tại cũng chưa hỗ trợ hết tính năng của Http2.

Nếu bạn chưa biết thì Http2 sẽ cho cung cấp cho chúng ta giải pháp ghép kênh (multiplexing) nghĩa là cho phép chúng ta sử dụng một http2 connection gửi nhiều request và response nhận về vẫn có thể biết được đó là của request nào. Còn việc gửi nhiều thì bản thân TCP socket đã giúp bạn gửi nhiều request rồi. Gửi nhiều request trên cùng một connection không phải là tính năng mới trên Http2. Tính năng mới trên Http2 là gửi nhiều request và response nhận về vẫn có thể biết được đó là của request nào ( Điều quan trọng phải nhắc lại 2 lần :)) ).

Vậy tại sao Http2 có thể làm được điều đó. Nó làm được điều đó vì mỗi request sẽ được đánh ID và được biết với tên Stream ID. Server và Client gửi request và response phải gửi kèm theo Stream ID này để có thể phân biệt với nhau.

Vì bài này không chia sẻ về Http2 và Http2 còn rất nhiều thông tin thú vị khác các bạn xem thêm tại bài viết : httpwg.org/specs/rfc7540.html#top

3.2. Đánh ID cho từng request

Trước khi Http2 ra đời, các công ty công nghệ lớn như Apple, Google đã sử dụng phương pháp đánh ID cho từng request để giúp phân biệt response thuộc về request nào. Cũng có thể đây là động lực cho sự ra đời của Http2. Cách này giúp chúng ta tái sử dụng được các connection được tạo ra mà không cần đợi response

Cụ thể hơn là mình đã được làm việc với service gửi thông báo về các thiết bị Android và IOS của 2 thanh niên công nghệ trên. Và 2 thanh niên này thì có tải cực kỳ lớn và do đó họ đều không sử dụng Http1.1 là công cụ giao tiếp chính cho client.

Cụ thể như sau :

• Apple : Gần đây APNS đã dịch chuyển từ TCP Socket sang Http2 giúp cho khách hàng có thể sử dụng một connection gửi nhiều thông báo với các máy IOS. Vậy trước đây khi sử dụng APNS tại project cũ bọn mình cần phải tạo ra kết nối TCP Socket đến Apple và mỗi khi push notify đến thiết bị IOS thì request mình gửi lên Apple sẽ phải đính kèm một unique id trên một connection. Và Apple sẽ trả lại kết quả qua Tcp Connection trên và sẽ đính kèm theo ID của request để mình còn map lại được request với response
• Google : Google thì cung cấp Firebase API dưới dạng Http1.1 và dạng XMPP. Dạng Http1.1 thì đơn giản dễ hiểu với mọi người nên nếu không có quá nhiều khách hàng sử dụng dịch vụ và không gửi nhiều request để notify thì hầu hết mọi người sẽ chọn giao thức này. Chúng ta sẽ không thể nghi ngờ khả năng của Google được nên khi chúng ta cần gửi nhiều thông báo khác nhau cho nhiều thiết bị khác nhau và sử dụng Http1.1 mà bị chậm thì chúng ta cần phải xem lại project của mình. Trong trường hợp này thì mọi người nên chuyển sang giao thức XMPP vì giống với Apple tại đây Google sẽ bắt client của mình tạo ra các ID khác nhau cho từng request gửi lên. Nhưng có một điều là giao thức XMPP không hỗ trợ dạng Batch nên nếu bạn cần gửi cho nhiều thiết bị và nội dung giống nhau 100% thì nên quay lại dùng Http1.1nhé.

4. Mình đã sử dụng phương pháp nào tại các sản phẩm đã làm.

Phương pháp hiện tại mình đang sử dụng cách đánh ID cho từng request sau đó gửi sang các Service thông qua :

• Non Blocking Socket (Sử dụng Netty) nếu share API cho bên ngoài. Sắp tới nếu có bên nào cần thì bên mình chắc sẽ viết dưới dạng Http2 server cho hợp thời đại.
• message queue đối với giao tiếp nội bộ của hệ thống.

Sau đó response sẽ đính kèm ID cũng gửi theo các đường này về client .

Hệ thống của mình giao tiếp giữa các service là dạng asynchronous điều đó khiến khi cao tải thì hệ thống cũng không tạo thêm các TCP connection để giao tiếp. Điểu đó cũng giúp giảm tài nguyên của hệ thống xuống khá nhiều.

Kết bài tại đây mình muốn khuyên cho mọi người khi xây dựng hệ thống nếu yêu cầu có tải lớn và độ trễ thấp thì nên di chuyển giao tiếp từ Http1.1 sang các dạng khác theo các công ty lớn như Apple, Google. Mặc dù cách này sẽ tốn rất nhiều thời gian gian đoạn đầu nhưng giai đoạn sau khi có nhiều khách hàng mọi thứ sẽ hoạt động trơn tru và không phải chịu cảnh hệ thống quá tải vì giao tiếp. Các bạn sẽ ít nhất không phải trải qua cảnh gateway của mình chỉ làm nhiệm vụ forward cũng sẽ tốn rất nhiều tài nguyên ( RAM, CPU).

Mình biết các thư viện và mô hình micro service có sẵn trên mạng có thể vẫn dùng chủ yếu là Http1.1 nên việc thay đổi mô hình không phải là điều dễ dàng.

Tại các công ty mình đã làm việc thì việc chọn giao tiếp dưới dạng REST API dưới dạng Http1.1 là điều thường xuyên xảy ra và cũng đã trải qua những đắng cay vì Http1.1 khi tải cao và số lượng connection nó tạo ra là quá lớn.

Tất nhiên việc tạo ra một hệ thống chạy tốt cần phải có nhiều yếu tố khác nhau nữa nhưng việc giao tiếp với các service là một điều cần quan tâm.

Bài này hoàn toàn là kinh nghiệm cá nhân trong quá trình làm việc rất mong có sự góp ý của mọi người để giúp mình và mọi người nâng cao khả năng lập trình.

Bài viết gốc được đăng tải tại demtv.hashnode.dev

Đọc thêm:

• Tìm hiểu thêm về HTTP/3 và so sánh với HTTP2
• Automation testing: Một số công cụ hữu ích cho tester
• 6 Điều Cần Tránh Khi Phỏng Vấn Để Tăng Cơ Hội Thành Công

Hàng loạt việc làm IT hấp dẫn trên TopDev đang chờ bạn ứng tuyển..

Bài viết được sự cho phép của tác giả Trần Văn Dem

Note for http2

Http2 là một giao thức truyền thông tin qua mạng một cách hiệu quả và tiết kiệm tài nguyên. Mặc dù đã được giới thiệu từ lâu nhưng không ít lập trình viên backend còn cảm thấy mới với loại protocol này. Sau khi tìm hiểu và áp dụng vào dự án thực tế mình muốn chia sẻ những kiến thức của mình về giao thức này với mọi người hy vọng giúp ích được cho mọi người trong dự án của mọi người.

Dự án gần đây mình làm là viết client giao tiếp với notify server của apple. Apple đã dịch chuyển từ giao tiếp thông qua từ socket sang Http2 server. Trong khi làm việc mình cũng tìm được một số thư viện đã được viết sẵn để giao tiếp với service mới này của apple như :

• java-apns
• pushy

Tuy nhiên để sử dụng thêm 1 thư viện mới vào product đang được chạy cũng có khá nhiều rủi ro vì cũng chưa có đủ thời gian để làm quen với chúng xem điểm mạnh, điểm yếu của thư viện. Tiếp đến việc ghép vào các interface có sẵn của project cũng khá khó. Nên mình tiếp tục tìm hiểu được một số thư viện có thể Http2 client viết sẵn trong java như :

• okhttp3
• netty

Trong bài này mình sẽ chia sẻ rõ hơn về 2 thư viện netty và okhttp3 này

Ứng dụng nổi tiếng nhất áp dụng Http2 mà mình từng biết là Grpc. Với Java thì Grpc sử dụng netty để xây dụng tầng transport của mình. Điều này khiến mình có thêm tài liệu là code của Grpc để tham khảo xây dụng http2 client để thao tác với Apple.

Bài blog này sẽ có code demo của các phần sau:

• Simple http2 server
• okhttp3 client
• Simple netty http2 client

Simple http2 server

Demo về tốc độ của http2 server so với http1.1 trên mạng là rất nhiều :

• http2demo.io
• http2.akamai.com/demo

Khi các bạn vào trình 2 web site trên sẽ thấy được tốc độ load tài nguyên thực sự là chênh lệch rất nhiều nếu sử dụng http2.

Vì tò mò nên tôi cũng tự xây dựng cho mình 1 http2 server để test tốc độ cũng như để làm server test cho client của mình. Tôi sử dụng Spring-boot để tự viết Http2 server vì với Spring boot bạn sẽ làm được điều này rất nhanh chỉ cần thay đổi trong file config là bạn đã có 1 Http2 server sử dụng spring boot rồi. Code demo tại package http2.server. Sẽ được đính kèm ở cuối bài viết này.

Tại code demo này tôi sẽ cho trình duyệt load 180 cái ảnh để so sánh tốc độ. Trước khi load ảnh mình sẽ cho luồng đó dừng lại 100 ms

    @GetMapping(value = "/gophertiles_files/{name}", produces = MediaType.IMAGE_JPEG_VALUE)
    public ResponseEntity<ByteArrayResource> getImage(@PathVariable String name) throws IOException, InterruptedException {
        Thread.sleep(100);
        final ByteArrayResource inputStream = new ByteArrayResource(Files.readAllBytes(Paths.get(
                "image/" + name
        )));
        return ResponseEntity
                .status(HttpStatus.OK)
                .contentLength(inputStream.contentLength())
                .body(inputStream);

    }

Kết quả của http2

Kết quả của http1.1

Trình duyệt của bạn sẽ chỉ dùng 1 connection duy nhất để load dữ liệu từ http2 server thay vì 6 connection chạy song song với http1.1 server. Bạn có thể check được điều này bằng tab network trong ảnh. Đây là kỹ thuật ghép kênh quan trọng đưa tốc độ load dữ liệu của http2 nhanh hơn nhiều so với http1.1. Mở ít kết nối hơn cũng đồng nghĩa với việc tiết được nhiều tài nguyên hơn cho cả phía client và server.

Http2 client

Sau khi có một server http2 thì việc tiếp theo là xây dụng các client để giao tiếp với http2 server trên.

Netty Http2 client

Tại code example của netty cũng có demo về việc xây dựng một http2 client đơn giản với netty. Tại demo này của mình cũng sẽ sử dụng code đó và thay đổi 1 chút để giải thích một số config khá quan trọng để xây dựng http2 client.

Tài liệu chi tiết về http2 các bạn tham khảo tại link sau : httpwg.org/specs/rfc7540.html#top

Tại link đó sẽ mô tả chi tiết cho chúng ta về : Stream, Frame, Error, config, … Nếu các bạn muốn tự mình xây dựng 1 client mà không dựa vào netty thì có thể tham khảo nhé. Mình chỉ đọc để biết code với netty như thế nào thôi. Code demo tại package http2.client.netty;.

Tại đây mình sẽ giải thích 1 số thứ quan trong khi sử dụng netty làm client ứng với tài liệu viết tại link https://httpwg.org/specs/rfc7540.html#top

• Stream Theo tài liệu của HTTP2 thì một connection sẽ sử dụng Stream để giao tiếp giữa client-server. Điều này giúp Http2 thực hiện ghép kênh trên cùng 1 kết nối TCP nhưng lại gửi được nhiều request. Mỗi Stream được định nghĩa bởi 1 ID vì vậy muốn biết được response này là của request nào thì mình cần phải biết được là Stream ID khi gửi request là gì và lưu lại. Theo tài liệu thì nếu là Client stream Id là một số lẻ bắt đầu từ 1,3,5,7,… Và nếu là Server thì sẽ bắt đầu từ 0,2,4,6,8,…

Khi bắt đầu thực hiện kết nối giữa client với server thì Client và Server phải gửi setting của mình cho nhau sau đó mới bắt đầu gửi request được. Điều đó giải thích cho việc trong code client demo của netty cũng như demo của mình để bắt đầu với Stream ID là 3. Tại class Http2ClientInitializer

    private int streamId =3;

    public int getCurrentStreamId(){
        int current =streamId;
        streamId +=2;
        return current;

    }

• Frame Http2 sẽ gửi nhận dữ liệu thông qua các Frame, Header Frame và Data Frame, Netty cũng cung cấp cho chúng ta api đọc dữ liệu của các Frame này. Tại bản demo này để đơn giản mình không đọc dữ liệu thông qua Frame mà nhờ netty làm giúp điều này. Nếu được ủng hộ mình sẽ có bài viết implement theo Frame này.
• SETTINGS_MAX_CONCURRENT_STREAMS Như đã trình bày ở trên thì khi thực hiện kết nối client, server sẽ gửi setting của mình cho nhau. 1 Trong những config quan trọng nhất cần quan tâm khi mình là client là SETTINGS_MAX_CONCURRENT_STREAMS. SETTINGS_MAX_CONCURRENT_STREAMS số này có ý nghĩa là server sẽ chấp nhận số lượng Stream đồng thời tối đa là bằng SETTINGS_MAX_CONCURRENT_STREAMS, client không được gửi quá lượng lượng Stream lên server không thì server sẽ đóng lại Stream và Client sẽ không nhận được kết quả. Với server demo sử dụng spring boot của mình số SETTINGS_MAX_CONCURRENT_STREAMS sẽ là 100 và được gửi trong HEADER của HTTP2Setting. Với server của Apple con số này sẽ là 1000. Nếu bạn có như cầu gửi hơn 1000 request đến Apple 1 lúc thì hãy tạo thêm 1 connection mới nhé.
• Với code demo trên thì bạn cũng nhận được kết quả là gọi 180 lần lên server với 1 connection thì kết quả sẽ là hơn 1 giây. Tất nhiên đây là 1 demo đơn giản nên nó sẽ chậm hơn trình duyệt 1 chút.

OKHttp3 client

Tiếp theo chúng ta sẽ sử dụng okhttp3 làm client. Vì code này ngắn nên bạn có thể xem Code demo bên dưới

package http2.client.okhttp;

import okhttp3.*;
import org.jetbrains.annotations.NotNull;

import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509TrustManager;
import java.io.IOException;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import java.util.Arrays;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;

public class OkhttpClient {
    public static void main(String[] args) throws Exception {
        OkHttpClient client = getUnsafeOkHttpClient();
        client.dispatcher().setMaxRequestsPerHost(1);
        Request request = new Request.Builder()
                .url("https://localhost:8082/test")
                .build();

        Response r1 = client.newCall(request).execute();
        System.out.println(r1.protocol());
        client.dispatcher().setMaxRequestsPerHost(100);
        CountDownLatch countDownLatch = new CountDownLatch(180);
        long startTime = System.currentTimeMillis();
        for (int i = 0; i < 180; i++) {
            client.newCall(request).enqueue(new Callback() {
                @Override
                public void onResponse(@NotNull Call call, @NotNull Response response) throws IOException {
                    response.close();
                    countDownLatch.countDown();
                }

                @Override
                public void onFailure(@NotNull Call call, @NotNull IOException e) {

                }
            });
        }
        countDownLatch.await();
        long time = System.currentTimeMillis() - startTime;
        System.out.println("time run " + time);
    }

    private static OkHttpClient getUnsafeOkHttpClient() {
        try {
            ConnectionPool connectionPool = new ConnectionPool(1, 3000, TimeUnit.SECONDS);

            // Install the all-trusting trust manager
            SSLContext sslContext = SSLContext.getInstance("SSL");
            TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());

            X509TrustManager manager = new X509TrustManager() {
                @Override
                public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {

                }

                @Override
                public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {

                }

                @Override
                public X509Certificate[] getAcceptedIssuers() {
                    return new X509Certificate[0];
                }
            };

            TrustManager[] managers = new TrustManager[1];
            managers[0] = manager;

            sslContext.init(null, managers, null);


            OkHttpClient okHttpClient = new OkHttpClient.Builder()
                    .followRedirects(false)
                    .sslSocketFactory(sslContext.getSocketFactory(), manager)
                    .protocols(Arrays.asList(Protocol.HTTP_2, Protocol.HTTP_1_1))
                    .retryOnConnectionFailure(true)
                    .connectionPool(connectionPool)
                    .build();

            return okHttpClient;
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

OkHttpClient có một nhược điểm là sẽ mở rất nhiều connection dựa theo số MaxRequestsPerHost .Nếu các bạn không set giá trị MaxRequestsPerHost thì mặc định sẽ là 6 giống như trên trình duyệt. Sau khi gửi request đến server và biết được server lòa http2 server thì OkhttpClient sẽ đóng hết tất cả kết nối lại và chỉ sử dụng 1 kết nối dành cho mục đích truyền tải dữ liệu với server. Đó là lý do tại sao mình lại phải gửi 1 request trước mục đích để khởi động hệ thống sau đó mới thiết lập lại số MaxRequestsPerHost. Tiếp theo nữa là MaxRequestsPerHost cũng tương ứng với số luồng được mở ra trong java để gửi nhận dữ liệu điều này cũng khá tốn thời gian. Và tại sao mình lại config số MaxRequestsPerHost là 100 thì đã được giải thích tại mục netty.

Khi sử dụng OkHttpClient mình hoàn toàn không lấy được setting của server để setting lại số MaxRequestsPerHost sao cho tối ưu nhất. Tiếp đến việc mở quá nhiều kết nối TCP tại thời điểm đầu tiên cũng là một nhược điểm của OKHttpClient. Việc sử dụng OKHttpClient sẽ làm code ngắn gọn hơn rất nhiều nhưng không mang lại hiệu quả tối ưu nhất khi sử dụng với product của mình. Việc disconnect và connect lại của OKHttpClent khiến mình không làm chủ được việc thiết lập config setMaxRequestsPerHost cho tối ưu.

Khi làm và tìm hiểu về OkHttpClient mình có đọc được 1 issue khá hot của nó tại link : github.com/square/okhttp/issues/3442

Tại issue này mọi người có nói đến việc MaxRequestsPerHost này. Trong có có người bình luận là I am sending warm up request and setting setMaxRequestsPerHost to 50. then when tried downloading images, Http/2 seems to be much slower than Http1.1 và chưa thấy ai giải thích việc này.

Mình xin giải thích việc này như sau để nếu như các bạn sử dụng OkHttpClient thì sẽ có thể tham khảo. Khi mình đọc code của OkHttpClient mình phát hiện ra số MaxRequestsPerHost này nếu bạn sử dụng HTTP1.1 thì sẽ tương ứng với mở 50 connection khác nhau đến server điều này hiển nhiên khiến bạn có thể tải được 50 ảnh cùng 1 lúc. Nhưng sao bạn set số MaxRequestsPerHost là 50 với Http2 lại có tốc độ thấp hơn khi so với Http1.1 vì theo lý thuyết nó sẽ gửi 50 request lên server 1 lúc. Điểu này lại ứng với server bạn gọi lên, mỗi server sẽ có các cách implement khác nhau để xử lý số lượng Stream bạn gửi lên. Mặc dù server trả lại cho bạn là có thể nhận > 100 (SETTINGS_MAX_CONCURRENT_STREAMS thường lớn hơn 100) request 1 lúc nhưng tại bản thân của nó sẽ chỉ xử lý 1 lượng Stream nhỏ hơn số này. Ví dụ với Http2 server demo vì mình dùng tomcat thì nó chỉ xử lý cùng 1 lúc là 20 Stream mặc dù nhận được 100 Stream. Config đó là maxConcurrentStreamExecution tham khảo tại tài liệu của tomcat mặc định số này là 20. Vậy tại đây có thể tạm hiểu là 1 connection của Http2 có thể bằng 20 connection của Http1.1

Vì các lý do trên bạn sẽ thấy tốc độ của HTTP1.1 khi MaxRequestsPerHost là 50 nhanh hơn Http2 nếu sử dụng Okhttp3Client. Nhưng trên thực tế sử dụng bạn không bao giở mở nhiều connection như thế vì nó tốn tài nguyên và cũng có thể bị server từ chối mở kết nối.

Khi nào nên sử dụng HTTP2

Với sự hỗ trợ mạnh mẽ của các server hiện nay thì mình nghĩ việc chuyển đổi từ HTTP1.1 sang HTTP2 là việc cần thiết và nên làm để tăng trải nghiệm khách hàng của bạn. Như bạn biết trình duyệt của bạn chỉ mở 6 connection vậy nên tốc độ không thể nào so sánh được với HTTP2 nên việc trải nghiệm dịch vụ của bạn sẽ bị tốt hơn nhiều khi sử dụng HTTP2.

Nếu bạn muốn truyền tải thông tin giữa các server nếu không cần cấu hình quá đặc biệt thì hãy thử sử dụng Grpc nó sẽ tiết kiệm rất nhiều tài nguyên và thời gian cho bạn. Mặc dù bạn có sử dụng Grpc thì cũng nên tự xây cho mình 1 Http2 server để học và tìm hiểu nó sâu hơn và cũng giúp bạn config Grpc một cách tối ưu nhất. Tất nhiên không phải cách tự xây dụng là sử dụng Tomcat hay Jetty nhé vì nó xây hết rồi lấy gì mà học hỏi nữa.

Nếu bài toán của bạn là xây dụng client giao tiếp với Apple thì mình khuyên bạn nên tự xây dụng dụa trên netty hoặc sử dụng pussy thay vì dùng okhttp3 mặc dù dùng okhttp3 là rất dễ nhưng nó sẽ không mang lại cho bạn 1 kết quả tốt nhất được.

Bài viết gốc được đăng tải tại demtv.hashnode.dev

Xem thêm:

• Mechanical Sympathy Là Gì? Lập Trình BackEnd bằng Java
• Tìm hiểu thêm về HTTP/3 và so sánh với HTTP2
• Cách Sử Dụng Middleware Trong NextJS

Top IT Jobs cho các Developers có trên TopDev

Bài viết được sự cho phép của tác giả Trần Thiện Khiêm

Nhiều bạn hỏi mình lập trình viên nên học ngôn ngữ gì, hôm nay mình xin giới thiệu một ngôn ngữ khá quen thuộc..

LỜI NÓI ĐẦU

Suốt hàng ngàn năm, con người đã sử dụng các ngôn ngữ lập trình để bắt máy tính phải “hiểu” mình và làm theo mệnh lệnh của mình. Các bạn đừng bị thị trường lừa dối, bởi vì máy tính vốn chỉ hiểu một ngôn ngữ duy nhất, đó là ngôn ngữ máy (machine code). Và trong khi các bạn diễn giải ý định của mình bằng java hay c# thì máy tính hoàn toàn không hiểu được. Và phải qua các bước biên dịch phức tạp thì máy mới hiểu được bạn muốn nói gì. Nhưng mà “tam sao thất bản”, chắc chắn máy tính sẽ không hiểu đúng 100% bạn ý định nói gì đâu. Mà coi như là máy tính hiểu bạn rồi, thì khi nào bạn sẽ hiểu máy tính?

Nếu bạn là người yêu máy tính, thích lập trình thì hãy nhanh chân học ngôn ngữ mà máy cũng hiểu và bạn cũng hiểu. Mình sẽ không bắt các bạn phải học mã máy, nhưng chí ít bạn nên học Assemb-Ly vì với máy tính, như thế là tuyệt lắm rồi. Assembly – Machine code nó tương đương 1-1 nên nếu biết assembly thì cũng tạm chấp nhận.

Đối với các bạn học bách khoa thì quả thật là may mắn vì các bạn đã được học assembly. Nhưng mà chắc là đã quên hết rồi nên trong bài này mình sẽ hướng dẫn lại căn bản cho các bạn.

Trong bài viết sử dụng MacOS và Xcode để lập trình nên bạn nào không có thì sử dụng trí tưởng tượng phong phú của mình.

CĂN BẢN ASSEMBLY

Data size: Các khái niệm cơ bản về kích thước của dữ liệu khi làm việc: byte (8 bit) -> word (16 bit) -> double words (32 bit) -> quad words 64 bit). Mình chỉ làm việc với 2 toán tử có kích thước tương đương.

Thanh ghi: Là các thanh nhớ đặc biệt dùng để tính toán. Khi tính toán thì chỉ thao tác với giá trị trên thanh ghi. (các thanh ghi general các bạn từng học như ax <=> al: (8 bit); ax: (16 bit); eax (32 bit); rax (64 bit))

Lưu trữ dữ liệu: Ngoài thanh ghi, có 2 vùng nhớ là stack và heap.

Lệnh: có các nhóm lệnh: đọc ghi dữ liệu / tính toán / điều khiển (lệnh nhảy – gọi hàm).

Nhãn (label): Mình có thể đánh dấu các câu lệnh, vùng nhớ bằng nhãn để có thể tham chiếu sau này.

Cú pháp: [<nhãn>:] <mã lệnh> nguồn[, đích]

Ví dụ:

movl $1, %eax; // gán eax = 1

move $1 to %eax (l nghĩa là kiểu long (4 bytes), b = bytes, w = word (2 bytes), q = quad words (8 bytes))

HELLO WORLD

Để bắt đầu, các bạn mở Xcode và tạo 1 dự án Command Line Tool, chọn ngôn ngữ là C. Bước tiếp theo, đổi tên main.c thành main.s và xoá hết code C trong main.s. .s là file chứa mã nguồn assembly.

Lúc biên dịch, bạn sẽ nhận được một thông báo lỗi như sau:

Undefined symbols for architecture x86_64:

 “_main”, referenced from:

    implicit entry/start for main executable

Thông báo lỗi này do chưa viết hàm main.

Chương trình assembly được chia thành nhiều đoạn (segment), cấu trúc căn bản như sau:

.section __DATA, __data // section data chứa data sử dụng trong chương trình

.section __TEXT, __text // section text chứa code trong chương trình

Chương trình muốn chạy được thì phải có symbol _main, do đó ta thêm symbol _main vào trong chương trình.

.section __DATA, __data // section that stores data

.section __TEXT, __text // section that stores executable code

.global _main

_main:

Chỉ thị global _main đăng kí với trình biên dịch symbol _main sẽ được public trong giai đoạn liên kết.

Bây giờ chúng ta đã biên dịch thành công, tuy nhiên lúc chạy chương trình sẽ gặp lỗi sau:

Thread 1: EXC_BAD_ACCESS

Hàm main chưa có gì thì làm sao mà chạy? làm sao mà chạy?

Lý do là hàm main hiện tại chúng ta chưa viết gì cả. Vậy hàm main sẽ làm gì? Chúng ta sẽ thử ra chỉ thị kết thúc chương trình.

_main:

movl $0x2000001, %eax

syscall

Nếu như trong MS DOS các bạn quen với interrupt (ngắt hệ thống) thì ở hệ thống 64 bit đó là syscall, các chương trình con của hệ thống. $0x2000001 là system exit(). Các bạn có thể tham khảo các chương trình con này ở

http://opensource.apple.com//source/xnu/xnu-1228.5.20/bsd/sys/syscall.h.

– Định nghĩa + tham số tương đương ở đây: http://opensource.apple.com//source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master

Như vậy chương trình của chúng ta đã chạy. Nhưng nó kết thúc ngay lập tức chưa kịp làm gì cả. Vậy làm sao để in ra chữ HelloWorld?

Nhìn trong file mình vưà gửi thì syscall 4 sẽ in viết một thông điệp ra dòng xuất chuẩn. Có 3 tham số : 1 là kí hiệu của dòng xuất (output stream) và 2 là thông điệp, 3 là kích thước của thông điệp

Ta chỉnh sửa lại chương trình như sau:

.section __DATA, __data

 helloMessage: .asciz "Hello World\n"

.section __TEXT, __text

.global _main

_main:

 movl $0x2000004, %eax // the print syscall function

 movl $1, %edi // standard output = 1

 movq helloMessage@GOTPCREL(%rip), %rsi // address to message

 movq $100, %rdx // size of the message

 syscall 

 movl $0x2000001, %eax // the exit syscall function

 movl $0, %ebx // exit code == 0

 syscall

Ta vừa thêm dữ liệu chứa dòng helloMessage vào segment data với nội dung là “Hello World\n”. Lúc biên dịch, nội dung này cũng sẽ được copy vào file thực thi, và lúc chạy sẽ hiện được tải vào data segment.

Để lấy địa chỉ của helloMessage, ta sử dụng cú pháp helloMessage@GOTPCREL(%rip), tương tự với toán tử lấy địa chỉ trong C: &helloMessage, sau đó ta gán vào tham số thứ 2, thanh ghi %rsi. Tham số thứ 3 là kích thước của thông điệp, ghi đại 0x100.

Sau khi gọi chương trình con số 4 của syscall, màn hình sẽ in ra dòng “Hello World”. Sau đó ta gọi chương trình con số 1 của syscall để kết thúc chương trình. Vậy là ta đã có chương trình “Hello World” đầu tiên. Xin chúc mừng!

!!!. Bây giờ bạn có thể yên tâm lên LinkedIn và cập nhật CV master Assembly.

Hẹn các bạn trong những bài viết tiếp theo về Assembly.

Bài viết gốc được đăng tải tại fanpage Khiem Tran – Programmer

Xem thêm:

• Stack Overflow Là Gì? Vì Sao Đệ Quy Lại Dễ Gây Tràn Stack
• Lập trình viên có nên học Assembly không?
• Coffee Talk: Anh Trần Thiện Khiêm – Từ Việt Nam đến GAFA

Đừng bỏ lỡ việc làm IT hàng đầu dành cho Top Devlopers tại TopDev!

Bài viết được sự cho phép của tác giả Nguyễn Hồng Quân

Làm việc trong lĩnh vực IoT (Internet of Things) nên tôi khá cần một hệ quản trị cơ sở dữ liệu chuyên dụng cho kiểu dữ liệu time-series (chuỗi thời gian), để lưu trữ dữ liệu do các thiết bị giám sát gửi lên.

Mặc dù IoT dựa trên những cơ sở công nghệ đã được phát triển từ lâu, thậm chí hệ CSDL time-series cũng không phải là khái niệm mới, nhưng mỗi nhà có một nhu cầu, nên mãi cho tới hồi đầu năm nay (2020), vẫn chưa có một hệ cơ sở dữ liệu nào thỏa mãn ý của tôi cả (khi viết bài này thì đã tìm được cái ưng ý).

Vậy nhu cầu của tôi khác với các đơn vị khác như thế nào? Đó là:

• Lưu trữ vĩnh viễn.
• Tự tóm tắt dữ liệu cũ.
• Chạy ổn trong máy tính nhúng.

Đa số các hệ CSDL time-series ra đời trước đây là phục vụ cho việc theo dõi “sức khỏe” của server (CPU/RAM usage) nên nó chỉ cần giữ lại dữ liệu trong một khoảng thời gian ngắn, vì vậy nhu cầu 1) không đáp ứng được. Ban đầu, khi mới bắt tay vào làm phần mềm cho AgriConnect, tôi tạm dùng PostgreSQL cho nhu cầu này, kết hợp với mẹo tạo chỉ mục (index) để đảm bảo tốc độ truy cập những dữ liệu mới ghi (để vẽ thành biểu đồ và để tính toán ra quyết định điều khiển thiết bị). Thời kỳ đó phần mềm của tôi nhắm chạy trên board BeagleBone Black nên những hệ CSDL viết bằng Java như Cassandra bị loại từ “vòng gửi xe”, dù chúng hay được nhắc đến tên trong các platform về IoT sẵn có (các platform này cũng viết bằng Java nên cũng bị tôi bỏ qua, sorry các bạn fan của Java).

PostgreSQL kết hợp với chiến thuật tạo chỉ mục hợp lý thì khá ổn cho nhu cầu hay gặp (vẽ biểu đồ, điều khiển thiết bị dựa trên dữ liệu đo đạc), cho đến khi chúng tôi bắt đầu có nhu cầu kết xuất (export) dữ liệu cũ nhằm đánh giá hiệu quả mùa vụ. Dữ liệu cũ này không được đánh chỉ mục nên khi kết xuất thì chạy khá nặng, làm BeagleBone quá tải luôn. Vì vậy tôi bắt đầu tìm kiếm thêm, vừa lúc đó thì InfluxDB ra đời (có lẽ nó ra đời trước đó rồi nhưng vẫn đang phát triển, còn sơ khai nên tôi không tìm thấy).

Sau khi chuyển đổi từ PostgreSQL sang InfluxDB thì những ngày đầu, kết quả rất phấn khởi: Do chuyên về time-series, với cách lưu trữ phù hợp, nên việc truy xuất dữ liệu gần đây hay dữ liệu cũ đều nhanh như nhau, tôi có thể dẹp bỏ script tạo lại chỉ mục dành cho PostgreSQL trước đó. Ngoài ra InfluxDB có chức năng tự tóm tắt dữ liệu cũ nên tiết kiệm được không gian lưu trữ.

Có điều niềm vui với InfluxDB chẳng kéo dài được lâu. Khi hệ thống hoạt động một thời gian, dữ liệu tích lũy đủ nhiều và InfluxDB càng cập nhật lên phiên bản mới thì nó càng bộc lộ vấn đề: ngốn quá nhiều RAM, chạy quá nặng. Để có thể duy trì hệ thống, tôi đã làm mọi cách để tối ưu bên phần của mình: sửa lại code, cắt bỏ nhiều lớp trừu tượng (ODM/ORM), tiết giảm xuống tới mức chỉ dùng câu SQL thuần khi truy cập InfluxDB, cắt một phần chức năng export ra viết lại bằng Rust. Tuy nhiên, cố gắng bên phía mình thôi vẫn chưa đủ, InfluxDB vẫn ục ịch ì ra đấy như trêu ngươi. Theo tôi, InfluxDB có một số quyết định công nghệ khiến “chúng ta không thuộc về nhau”:

• InfluxDB dường như hướng đến việc truy cập từ front-end, nên chọn HTTP 1 làm giao thức truyền tải. Giao thức HTTP không những là dạng text (InfluxDB không dùng HTTP/2) mà còn bắt buộc kèm theo một mớ header, khiến tăng overhead: không những nội dung truyền đi nặng thêm mà cả hai phía đều phải tốn thêm công parse các header HTTP nữa (ngoài ra, là một giao thức dạng text đồng nghĩa với việc thêm bước encode/decode base64 khi cần truyền dữ liệu nhị phân). Để ý là hệ CSDL phía backend như PostgreSQL dùng giao thức dạng binary cho tinh gọn. Hậu quả của việc dùng HTTP là như kết quả profile dưới đây, các phần code khác của tôi đã được tối ưu và chạy còn nhẹ hơn thư viện client để truy cập InfluxDB:
• Dùng ngôn ngữ Go. Nói câu này có lẽ sẽ gây tranh cãi nơi fan của Go. Nhưng thực tình, tôi đã bắt gặp tâm sự của tác giả InfluxDB đâu đó rằng, anh ta lỡ chọn Go vì khi bắt tay vào xây dựng, anh ta chưa biết đến Rust. Ngoài ra, việc chọn Go hình như cũng vì InfluxDB muốn tốc độ ra sản phẩm nhanh. Chỉ trong vài năm mà công ty đằng sau InfluxDB đã cho ra một bộ nhiều sản phẩm liên quan chứ không phải mỗi database, có thể thấy ưu tiên của họ không phải là hiệu năng cao, nên việc chọn Go là hợp lý với hướng đi đó.

Khi tìm kiếm phương án thay thế InfluxDB, tôi đã bắt gặp TimescaleDB. TimescaleDB ra đời sau InfluxDB nên lúc tôi biết về nó thì nó vẫn chưa đủ tính năng để tôi có thể đem về dùng. Tuy nhiên, tôi đã thấy ngay triển vọng về hiệu năng cao, vì:

• TimescaleDB được viết dưới dạng extension của PostgreSQL, nên cũng viết bằng C.
• Cũng vì là extension của PostgreSQL nên giao tiếp với nó bằng giao thức của PostgreSQL, không đụng phải overhead như HTTP của InfluxDB.
• Khi dùng giao thức của PostgreSQL thì tôi có cơ hội dùng một thư viện tốc độ rất cao của Python là asyncpg (theo benchmark trong link thì nó còn ăn đứt cả Go).

Khi nhìn thấy tiềm năng đó thì tôi rất háo hức, và chờ đợi. Chờ đợi mãi khi PostgreSQL chuyển dần dần từ 9.6 lên 10, 11 thì mới thấy TimescaleDB có đủ tính năng tôi cần. Cũng phải mất hơn nửa năm để tôi sắp xếp công việc, thời gian để có thể bắt tay vào thực hiện một sự thay đổi lớn về cấu trúc công nghệ bên trong platform IoT của AgriConnect.

Ban đầu có một trở ngại suýt nữa khiến tôi phải đình chỉ công việc, đó là TimescaleDB không cung cấp gói *.deb cho BeagleBone Black. May thay tôi tìm được script đóng gói cho Ubuntu của họ trên PPA, đem về chỉnh chọt một hồi cũng ra được script đóng gói dành cho BeagleBone. Các gói *.deb dành cho BeagleBone đang được lưu trên kho của AgriConnect.

Khi tôi viết bài này, phần mềm của AgriConnect đã chạy với TimescaleDB được 3 tuần trên các server của khách hàng. Sau 3 tuần quan sát thì thấy sự khác biệt thật rõ rệt. Nếu như trước đây tôi phải dành riêng một server chỉ để chạy mỗi InfluxDB, giảm tải cho khác server khác thì nay server đó phải thất nghiệp ngồi không. Ngay cả khi lần này đã mang lớp ORM trở lại thì vẫn chạy nhẹ hơn cả khi dùng InfluxDB với lớp ORM/ODM bị lược bỏ.

Bài viết gốc được đăng tải tại quan.hoabinh.vn

Bạn có thể xem thêm:

• Khởi Đầu Dự Án Python Như Thế Nào Để Thuận Tiện Phát Triển Lên
• Scrum Master là gì? Tìm hiểu các vai trò chính của Scrum Master
• Giới thiệu nền tảng máy học ML.NET của Microsoft – Bài 1

Top Developers đừng bỏ lỡ Top việc làm IT trên TopDev nhé!